LP on .NET

July 7, 2009

Visual Studio 2008 Unit Testing Bug

Filed under: .NET,C#,Visual Studio,VSTS — Larry Parker @ 11:47 am

I just ran into a bit of a nasty bug in Visual Studio 2008 while doing some unit testing.  At some point after a bunch of edit / compile / unit test iterations, I got the following error trying to compile my solution:

API restriction: The assembly ‘file:///C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll’ has already loaded from a different location. It cannot be loaded from a new location within the same appdomain

Restarting Visual Studio did not help.  Neither did cleaning and rebuilding my solution.

I found this thread on the MSDN VSTS forum which discusses the problem.  Microsoft apparently could not reproduce the problem, and closed out a bug report submitted to Microsoft Connect as “Closed (Not Reproducible)”.

If you’re running into this problem, I recommend reading through the entire forum thread, because the solution does not seem to be so cut and dry.

But for me, deleting my solution’s user options file (e.g. MySolution.suo) did the trick.

Hope this helps.


August 4, 2007

VSTS and Team Foundation Server

Filed under: .NET,technology,TFS,Visual Studio,VSTS — Larry Parker @ 1:03 pm

I have been using Visual Studio Team Systems & Team Foundation Server for source code control for a couple of projects this year.  So far so good, but it wasn’t until last Friday that I really took a liking to it.

I needed to reorganize my team project’s folder structure (our trunk) and then branch off the trunk so we could have a copy for maintenance and continue on with our main development.  Although I was a bit hesitant to start moving folders around on the server, TFS really did a good job at it.  Definitely make a backup of your local workspace (i.e. your developer desktop) because TFS will move things around there too (based on your TFS workspace mapping), but overall TFS was pretty smart about things.

One manual step I had to do after changing the folder structure was to overlay the subfolders and files on my local machine that TFS did not know about that got left behind (e.g. some local projects and files that I did not check in).  This was easy to do, and I’m glad TFS had the intelligence to leave the folder if it wasn’t empty after moving everything it did know about.

Branching was very easy as well.  Just right-click on the server-side folder and select Branch from the context menu.  I chose to branch from the latest version, but the other options like branching from a label or date are useful too.

Now for the really good part… I had to make a couple of small coding changes (bug fixes) on the trunk that also needed to get to the newly created branch.  With my previous source control system, I would have checked the .cs files out in both places, made the changes in one set of files, and then copied and pasted to the other files, and then checked everything back in.

TFS provides a much better solution with its merge capability, and even let me merge based on a changeset so I didn’t have to specify all the files (it knew from the changeset).

Anyway, just thought I would share these TFS successes.  It really is a big help for managing source control and team projects.  My next step will be to build our projects on a dedicated build machine that gets everything from TFS (instead of doing builds locally).

Create a free website or blog at WordPress.com.