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’
I recently updated my Nokia Lumia 800 to the latest build, 1600.2483.8106.11500.
I’ve been keeping an eye on the battery capacity of my Lumia 800 following the reported battery charging issues using the phone diagnostics (which can be accessed by entering ##634# on the phone keypad, then from the list of applications afterwards) and noticed that following the update to the latest build, the reported full charge capacity started dropping. Initially it was around the 1350 mAh mark, following one full charge it dropped to about 1250 mAh, following the next it dropped to about 1140 mAh. Over the next couple of days it rallied a little, settling eventually at about 1180 mAh.
In reality I wasn’t too worried by the apparent drop in charge capacity, especially as the runtime following a charge was a good step up on what it had been before the update, but was concerned enough to drop Nokia a quick e-mail to ask them about the issue in case it was something they’d not come across before. My phone’s reported runtime was also lower than others in the office were reporting for theirs and I’ve seen some experiencing similar issues with their Lumia 800s on the Nokia forums.
Nokia’s support has been excellent. Following my initial e-mail to them, I had two very quick responses by e-mail asking for a few more details, followed by a call offering to collect the phone to run some diagnostics on it. Following a quick conversation with Robert however, it looks like I won’t need to take them up on their offer…
The solution in my case was to stop the tasks running in the background on my phone. After stopping the background tasks (go to settings, then slide one screen over to applications, then select background tasks and stop anything that is showing as running), RAC Traffic and one other in my case, I rechecked the battery diagnostics, and not only showed that the current being used had dropped by about half, but the reported battery full charge capacity had returned to it’s original state of over 1400 mAh.
Quite why a couple of running background tasks were influencing the reported full charge capacity of the battery, I’m not quite sure, but the method seems to be a reliable way to return the reported capacity of the battery to its full value.
Thanks to everyone who attended our SDL event today. Here are a few links to information we mentioned
Do you enjoy our Black Marble events, but can’t always make it in person? Busy day at the office, mean you can’t attend a full or even a half day event? From 30 January 2012, we are introducing a series of online seminars – running most Mondays though to the end of June, we are covering a range of topics in bite-size sessions. Follow the links for more information and to register – or call on 01274 300175 for more details.
30 Jan – Search Architecture
06 Feb – What is new in Azure?
20 Feb – Why Migrate from Visual SourceSafe to Visual Studio Team Foundation Server
12 Mar – Content Management with Avviso and SharePoint 2010
19 Mar – Visual Studio Team Foundation Server for Everyone
26 Mar – An Introduction to SQL 2012
16 Apr – Introduction to Azure
23 Apr – An Introduction to Lab Management
30 Apr – Microsoft Surface – It is not just Touch
14 May – Designing for SharePoint
21 May – How to Kickstart your ALM Process
28 May – Designing Applications for the Windows Phone
11 Jun – Creating Data Aware Visio Diagrams in SharePoint 2010
18 Jun – What is New in Azure?
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