IMHO Visual Studio 2010 Lab Management is a l33t product. At this point in time, there is no word on the pricing but I going through the Visual Studio 2010 Licensing White Paper I don’t think that it will be cheap, furthermore I am also a bit  afraid that in a lot of companies it will be a bit hard to sell because of company politics as it is possible that your company is already using for example VMware vCenter Lab Manager and they might not be willing to just throw that away (yet).

David Baliles, the Enterprise Tools Strategist @ Microsoft posted on his MSDN blog a whole bunch of Visual Studio 2010 Lab Management videos which are worth checking out.

Click here for the videos.

Microsoft released a Virtual PC image with an installed version of the April 2008 CTP of Visual Studio Team System Code Name "Rosario", the version following Visual Studio Team System 2008. These are the accounts used in this VPC image:

• Username: TFSSETUP, password: tfssetup
• Username: TFSSERVICE, password: tfsservice
• Username: TFSREPORTS, password: tfsreports

The download size is a whopping +8GB...

Visual Studio® Team System Code Name "Rosario" April 2008 CTP (VPC Image)

For a particular solution when I try to run the tests I get the following error dialog:

---------------------------
Microsoft Visual Studio
---------------------------
Exception has been thrown by the target of an invocation.
---------------------------
OK  
---------------------------

Anyway the problem just went away... Don't you love this crap?

I have been sick for more than a week (flu) and started back working yesterday and I did not miss all the problems associated with my daily jobs at all.

The problem I am trying to tackle today is a strange one. Every time I try to "Force Get" the latest version of our Team Project I am confronted with the following dialog:

---------------------------
Microsoft Visual Studio
---------------------------
D:\Projects\lozanga\ProjectX\Source\Core\Mainline\Source\DataContracts\TimeData.cs: Access to the path 'C:\Users\lozanga\AppData\Local\Temp\TFSTemp\5016{#$@;._}5044' is denied.
---------------------------
OK  
---------------------------

The only thing I figured out is that the first part of the file name (or directory?) namely 5016 in this case is the Process ID of Visual Studio and the last portion namely 5044 is the Thread ID. When I try to figure out what exactly is happening here by attaching a debugger to the Visual Studio instance I don't see thread 5044.

So far what fixed this is uninstalling the McAfee VirusScan...

Yesterday when opening one of our solutions I received the following dialog:

I remember having the same problem more than a year ago with a Visual Studio 2005 solution and the problem was that we had duplicate GlobalSections in the .sln file. So hoping that this time we had the same problem I opened the .sln file in Notepad and I saw that we had the following double-section with different info:

GlobalSection(TeamFoundationVersionControl) = preSolution

What I did to solve this was first unbind the solution from TFS. Remove these double GlobalSections manually in the .sln file and then rebind the solution. Problem solved!

Jeff Beehler posted on his blog a link to a survey on the usage patterns for Visual Studio Team System Architecture Edition.

Yesterday evening and this morning we have had a crash of our TFS machine and now I cannot list the Build Definitions or manage the Build Agents:

Followed by the following dialog:

I have tried out all the TFS Web Services and they all work except for the Build Web Services. When I navigate for example to http://TFS:8080/Build/v2.0/BuildService.asmx I get the following error:

TF10216: Team Foundation services are currently unavailable. Try again later. If the problem persists, contact your Team Foundation Server Administrator.

After restarting the IIS services with net stop W3SVC and net start W3SVC the problem was solved:

Today I was trying to create a new Build Definition but when I tried to create a new TFSBuild.proj file the following error dialog popped-up:

The funny thing is that the first part of the path is the folder I pointed to the last time when I added a "File reference" to a project in a solution that is not even open in my Visual Studio instance. So I restarted Visual Studio to see if that would solve the problem but then I got the following error dialog:

The 2nd part of the path is strange too because $(BuildDirectory) is an environment variable I specified on the build machine that points to the folder D:\Builds\:

So apparently using environment variables is not supported in the working directory of the Build Agent. As a workaround I replaced $(BuildDirectory) with D:\Builds\:

By the way I already tried defining the environment variable BuildDirectory on my local machine hoping that this would solve the problem as well but that does not work.

UPDATE:

Swaha Miller, one of the devs on Team Build, has let me know that BuildDirectory happens to be a known property within the .targets used by Team Foundation Build, so basically it is a coincidence that I happened to define an environment variable which was already known. Changing the name of the environment variable to something else fixes the problem!

This evening I was the only one working on a solution as the rest already went home and I could see that the .sln file was checked by someone:

Looking in the Source Control Explorer I could see that the .sln file was not checked out:

I tried refreshing the Source Control Status but that did not change a thing (File => Source Control => Refresh Status):

Using Team Foundation Sidekicks I looked for shelvesets that had the .sln file checked out and found 2 obsolete shelvesets. After deleting these shelvesets and refreshing the Source Control Status I could see that the .sln was no longer appeared as being checked out:

I remember having read about this issue recently on a blog so I performed a search in my JetBrains Omea Reader and found this post by Marcel de Vries (MVP Team System) on 3rd December 2007. On his post he explains what is causing this behavior. So the full credits go to him for solving this problem goes to him.

I have noticed that when you have multiple Test Configurations (*.testrunconfig) and you try to switch between them that you need 2 attempts. I have noticed the .vsmdi file will be checked out on the first attempt. On the 2nd attempt the .vsmdi file will be successfully updated with the new Test Configuration data. So to switch between Active Test configurations you need to first check out the .vsmdi file:

Then switch from Test Run Configurations:

You will see that it well then successfully switch the Active Test Run Configuration:

This looks like a bug IMHO.