Last year I presented at Microsoft UK’s Techdays on Visual Studio 2010 Lab Management and the session was videoed. I recently tried to refer someone to this recording and I found that the Techdays site had been rebuilt for this years event and I could not find the video. Well after a bit of searching I found it on MSN at Putting some Testing into your TFS Build Process
Next Tuesday lunchtime (12th Apr 2011 1pm) I will be doing a webcast on on ‘Lab Management and Automated Build’. I will be looking at the build options in TFS and also how they can be extended with Lab Management.
The event is free to attend you just need to register at http://www.microsoft.com/visualstudio/en-gb/visual-studio-events
Whist recently installing a TFS 2010 system onto a single box server, that was also a domain controller, I had a problem that though everything seemed in order I could not view my reporting services based reports in either SharePoint or directly from the http://myserver/reports interface.
During the installation I had verified I had the correct password for my [domain]\tfsreports account used to run the reports. If went to the http://myserver/reports page and edited the TFS2010ReportsDs or TFS2010OlapReportDS and tried to test the [domain]\tfsreports login it failed. However, if I swapped to the [domain]\administrator all was fine and my reports worked.
So what was the issue?
The key point is that the server, as it is a PDC, would only allow limited accounts to login to the server console. The actual Reporting Services web services were running as a named domain account (you cannot use Network Service and like on a PDC), but it seems that the connection by the [domain]\tfsreports account is considered the same as a login via the login screen as far as security systems are concerned.
The immediate fix was to make sure the [domain]\tfsreports user was in a group listed in the “Allow log on locally". To check this
- Run gpedit.msc
- Expand Computer Configuration\Windows Settings\Security Settings\Local Policies
- Click on User Rights Assignment
- Ensure that "Allow log on locally" includes user required, or that the user is in one of the listed groups
Now I am not sure this is the end of story, I am sure I can waste loads of time to find out exactly the minimum security settings needed, but this is an adequate solution for no for me.
I posted a while ago about common confusion I had seen with Lab Management. We I have recently managed to get myself completely confused whilst working with Lab Management. It turns out the issue was so obvious I managed to miss it for hours, but as usual I learnt a good deal whilst trying to troubleshoot my stupidity.
I have a Lab Management system linked up to a a Team Project Collection (TPC). In this TPC there is a Team Project used for SharePoint development and on my Lab Management system I have an environment to allow testing of the SharePoint products. I setup a new Team Project in this TPC. In the new project I created a new MVC solution and created an automated build, which all worked fine.
I wanted to deploy this MVC application to a web server in an environment in my Lab Management system. So I created a basic web server environment and deployed it onto a host in my Lab. I then tried to create a Lab Management workflow build to deploy to the newly created environment. However the combo to select the environment was empty when I ran the wizard.
I was confused, I knew I had an environment on the Lab Management system, I had just created it in Test Manager (MTM) I could attach to it in MTM or Remote Desktop.
So I checked again
- that the TPC was correctly registered with Lab Management
- the environment was running in MTM
- that all the configuration for the Team Project looked OK via TFSLABCONFIG.EXE
All to no avail. Then after far too long I realised I was not looking at the same things in MTM and Visual Studio.
When you are in the Lab Center (green border) pages of MTM there is no obvious indication of the Team Project you are using. I had forgotten this and got it into my head I was looking at all the environments and libraries for my whole TPC. THIS IS NOT THE CASE. The environments and libraries are Team Project specific and not TPC specific. I had created my new environment in my SharePoint team project not in my new MVC one.
To swap Team Project I needed to change to the Testing Centre (blue border) view and change the Test Plan (top right)
to get the dialog to change the Team Project.
Once this is done you can go to the Lab Center again and you see the environments for the selected Team Project. This was where I needed to create my environment.
At this point you will notice that all the templates and VMs you imported into the other Team project are not in this one. You have to reimport them from SCVMM and then create the environments in MTM for that Team Project
To the technical tip here is remember that Lab Center in MTM is Team Project specific – NOT Team Project Collection specific, but it does its best to not remind you of this fact so it is easy to forget.
I got round to installing Visual Studio 2010 SP1 on my laptop last night; well I started last night via the Web Platform Installer method. It downloaded the bits fast but sat for ages on the first step, installing the actual service pack. There was no obvious activity on the CPU or disk. In the end I gave waiting and went to bed. I was pleased to see it was finished this morning.
So the tip here is be patient, applying this service pack is a job you start on your desktop before you go home, not when you come into the office.
So what is the biggest benefit thus far?
I can easily use IIS Express from with Visual Studio, so no more having to run Visual Studio as administrator to us my local IIS Server for development.
At the end of the month I will be speaking at a series of free Microsoft events in Belfast and Dublin. There going to be two session at each location
Managing application lifecycle “From requirements to retirement” with Team Foundation Server 2010
Better testing with lower costs - Saving your teams time and resources using Visual Studio 2010 and Microsoft Test Manager
So if you are in the area why not pop by?
I am doing some work on VS2008 at present and I when I started my VS2008, which I had not used for a while, I was plagued by errors along the lines of "The operation could not be completed". These occurred when running major features such as:
- Loading LINQ to SQL Designer
- Running the SQL 2008 Project Wizard
The fix turned out to be resetting the package skip loading flag. It seems a number of add-ins were not being loaded on startup. This command is run from the "Visual Studio 2008 Command Prompt" by typing
I also had problems trying to run tests using the standard Microsoft Test tools within Visual Studio. I got the error “Exception has been thrown by the target of an invocation”, but running tests using TestDriven.NET worked fine. This problem was not fixed with the /resetskippkgs. However, turns out it is a known issues if VS2008 SP1 and TFS, KB980216. The quick fix is to make sure I was connected to a TFS server. Once this was done the test could be run. There is a hotfix, but I can live without I think for now.
So the moral is, even if you don’t use an IDE everyday you can still break it with all the patching you do around it for other IDEs and underlying frameworks. A reset to defaults can often by just the kick it needs to get it working.
Today we have seen the release of the Visual Studio 2010 SP1 and the TFS-Project Server Integration Feature Pack. Both are available on the MSDN download site.
As well was the new downloads they have announced a change to licensing over Load Test Agent. This gives Visual Studio Ultimate with MSDN users the ability to do unlimited load testing. No longer do you need to purchase Load Test Packs, thus making load testing an option for more teams.
For more details see Brian Harry’s blog post on the new downloads and load testing
Many development teams hit the problem that they have dependencies on libraries that they do not want to have as part of their solutions. If these dependencies are open source projects then there are options using technologies like NuGet or OpenWrap. However, in many cases the dependency is to an internal project, such as the company standard logging library, which it is never going to put up into a centralised repository. So normally you end up with either:
- Adding the project for the shared assembly to the solution and rebuilding with the solution, probably via some branching model in source control to allow fixes to be merged between projects.
- Adding the assembly from a known location (maybe under source control) that the team responsible for then shared library publish the current version to.
Both solutions can work, but they both have their pros and cons.
A different and interesting approach has been proposed in Sven Hubert’s post “Extended Dependency Management with Team Foundation Server” on http://www.TFSBlog.de. He suggests using a custom MSBuild task and .Targets files that allows you to cause an external project to be rebuild from source control (addressing option 1 without the need to add the actual VS project to the solutions) or to pick the built assemblies from the a given Team Build (addressing option 2).
If this problem is one you have come across this post makes for interesting reading.