We have been building ‘standard’ environments for our TFS Lab Management system. Environments that can be used for most of the projects we are involved in without too much extra setup e.g. a small domain controller VM and a Server VM with SQL and SharePoint. These environments have a series of snapshots so it can be used in a number of ways e.g if we just want SQL and IIS we just go back to a snapshot prior to SharePoint being installed.
When trying to deploy one of these environments we saw a couple issues.
First we got the error that there was not a suitable host with enough capacity to host the environment (remember all the VMs in a network isolated environment need to be on the same Hyper-V host). This can be a bit of a red herring as with dynamic memory and other new Hyper-V features there is often the capacity there (see Tiago’s post on this for more details). The fix here was to set TFS to allow aggressive deployment using the command
C:\Program Files\Microsoft Team Foundation Server 2010\Tools>tfsconfig lab /hostgroup /collectionName:myTpc /labenvironmentplacementpolicy:aggressive /edit /Name:"My hosts group"
The next problem I saw was that when the new environment was deployed it did not started cleanly. The first time an environment is started it seems to take longer than subsequent starts (assume there is some initial configuration done). Basically in this case network isolation did not start correctly, hence build and testing capabilities also failed.
The fix was simple, shut down the environment and start it again. The tried and trusted IT answer to all problems. This time it started fine, and was faster to start.
Now I have not see this issue every time I deploy. When I deployed the same environment again and it worked perfectly first time. I suspect it was really a capacity issue on the underlying Hyper-V server causing some delay, but I am running in aggressive mode so I should expect this.
If you want to hear a bit more detail on some of the common security issues we discussed at yesterdays SDL event why not listen to Troy Hunt Secures ASP.NET recent show on .NET Rocks or download his PDF ‘OWASP Top 10 for .NET developers’
Thanks to everyone who attended our SDL event today. Here are a few links to information we mentioned
A new 22.214.171.124 release of the Community TFS Build Extensions has been published today. This contains some fixes and two new activities
For many years Black Marble has run free events on a wide range of technologies. Originally we only ran these locally in Yorkshire, but as time progressed we have run them across the UK and Eire. They are a great way to help your staff whether technical or managerial get up to speed with new developments in our industry.
For 2012 we have decided to try running some events online. The format for these events will be a short 30 minute interactive sessions where you will have the chance to see a short presentation and/or demonstration on a technology followed by a Q&A session with the presenter.
Hopefully these will prove to be as successful as our other events.
A common cause of the TF266026 error is because when the build agent tries to start (it is the build agent that runs the workflows in Lab Management) it cannot access the custom assemblies folder as defined for its parent build controller. Obviously this problem only occurs if you have set a custom assemblies path for parent build controller.
The reason for the error is because the agent is running as the Lab Management service account, in my case tfs2010lab, as defined for the TPC in the TFS Administration Console. This account by default has no rights to the source folder assigned for the custom assemblies. This is not usually an issue until it needs to access source control to load custom assemblies (which actually it probably does not ever use as it is not building code!).
As soon as this service account is granted access to this folder, by making it a reader, contributor or builder on the team project, the problem goes away.
Whilst upgrading a TFS 2010 build today to the new 1.2 release of the Community TFS Build Extensions we hit an issue. All seemed to go OK until the build tried to use the StyleCop activity, which failed with the error
Showing a modal dialog box or form when the application is not running in UserInteractive mode is not a valid operation. Specify the ServiceNotification or DefaultDesktopOnly style to display a notification from a service application.
After a bit of pointless fiddling we decided the only option was to set the build service in question to run interactively (set on the build service properties in TFS administration console on the build box). Once this was done the following dialog popped up
On checking the assemblies copied into the CustomAssemblies folder referenced by the build controller we found we had an older version of this file (from the previous release of the build extensions).
Once we replaced this file we got a bit further, we did not get a dialog, but the build failed with the error in the log
Error: Could not load file or assembly ‘StyleCop, Version=126.96.36.199, Culture=neutral, PublicKeyToken=f904653c63bc2738’ or one of its dependencies. The system cannot find the file specified.. Stack Trace: at TfsBuildExtensions.Activities.CodeQuality.StyleCop.Scan() at TfsBuildExtensions.Activities.CodeQuality.StyleCop.InternalExecute() in D:\Projects\teambuild2010contrib\CustomActivities\VS2010\MAIN\Source\Activities.StyleCop\Stylecop.cs:line 134 at TfsBuildExtensions.Activities.BaseCodeActivity.Execute(CodeActivityContext context) in D:\Projects\teambuild2010contrib\CustomActivities\VS2010\MAIN\Source\Common\BaseCodeActivity.cs:line 67.
The issue was we had not upgraded the StyleCop assemblies in the CustomAssemblies folder to match the ones the 188.8.131.52 release of the build extensions was built against (it needed 4.6.30, note not the latest 4.7.x.x.). So we changed these files to the 184.108.40.206 release and the build worked
Interestingly note that the file names have changed from the 4.4.x.x. to 4.6.x.x release of StyleCop from Microsoft.StyleCop.*.dll to just StyleCop.*.dll, so make sure you delete the old files in the CustomActivities folder to avoid confusion.
To the top tip here is to make sure you update all of the assemblies involved in your build to avoid dependency issues.
It can be a bit confusing to get work out which tools to use at which stages required to get a lab environment up and running in TFS. Here is a basic workflow showing what you need to do in System Center Virtual Machine Manager prior to starting in MTM Lab Center
Note: if you want to copy environments between TFS Team project Collections have a look at this post
I got a TF260073, incompatible architecture error when trying to deploy a new virtual lab environment using a newly created VM and template. I found the fix in a forum post.
The issue was that when I had build the VMs, I had installed the Lab Management agents using a VMprep DVD ISO and mounted it using ‘share image instead of copying it’ option. This as the name implies means the ISO is mount from a share not copied to the server running the VM, this save time and disk resources. When I had stored my VM into the SCVMM Library I had left this option selected i.e the VMPrep.iso mounted. All I had to do to fix this issue was open the settings of the VM stored in the SCVMM Library and dismount the ISO, as shown below
Interestingly the other VM I was using in my environment was stored as template and did not suffer this problem. When creating the template I was warning that it could not be created if an ISO was mounted in this manner. So the fact I had a problem with my VM image should not have been a surprise.
When using TEE in Eclipse 3.7 on Ubuntu 11.10 there is a problem trying to view a TFS build report. If you click on the report in the Build Explorer you would expect a new tab to open and the report be shown. This is what you see in Eclipse on Windows and on older versions of Eclipse on Linux. However on Ubuntu 11.10 with Eclipse 3.7 you get a File Download dialog.
I understand from Microsoft this is a known issue, thanks again to the team for helping get to the bottom of this.
The problem is due to how Eclipse manages its internal web browser. Until version 3.7 it used the Mozilla stack (which is still the stack used internally by TEE for all its calls), but with Eclipse 3.7 on Linux it now uses WebKit as the stack to open request URL such as the build report. For some reason this is causing the dialog to be show.
There are two workaround:
Set Eclipse to use an external browser
In Eclipse –> Windows –> Preference, select use external browser
When you now click on the build details an external browser is launched showing the results you would expect.
Switch Eclipse back to using Mozilla as its default
You can switch Eclipse back to using mozilla as its default. In your eclipse.ini set
Once this is done Eclipse should behave as expected, opening a tab to show the build report within Eclipse.