I've been doing some MSBuild experiments lately and pondering what a build server should look like and ran into an interesting challenge:

Suppose I am trying to build an application that references some third party assembly (a pre-built assembly that is not part of the solution being built)--a good example of this might be a project that references Log4Net.  How can I ensure that my solution will build successfully and not encounter broken references to the third party assemblies that I use?

I know how to reconcile broken references on my desktop--I covered that in my Resolving Reference Problems post.  However, I shouldn't be checking in .USER files in source control, so that solution isn't relevant here.

I could hardcode a full reference path to something like C:\Program Files\log4net, but how do I know that's where the Build Masters have installed the binary?

You're probably saying, "Brad, you dummy, just add the binary to a solutions folder in your solution and reference it with a relative path!"  Well, let's just assume that my friendly neighborhood Source Control policeman won't let me check in files that are not explicitly source code--of which, I guess, a DLL is not.  What now?

What's interesting is that, so long as MSBuild can find my third party assembly in the GAC of the build server, it doesn't matter where the DLL lives in the rest of the file system: C:\Program Files\log4net, C:\Program Files\some-mysterious-sub-dir, wherever (or nowhere, as in, the Build Master deletes the binary after he installs it to the GAC).

Further, if you create such a scenario on your Dev machine and open up the project in Visual Studio 2008, you don't get the dreaded broken reference symbol (and your solution will compile).  I wonder if that's a new thing in Visual Studio 2008?  I could have sworn that Visual Studio 2005 would still show me broken  references when my hintpaths wouldn't resolve to a physical assembly even if that assembly was in the GAC.  Hmm.

Anyway, I had several JPGs to attach showing how I arrived at my conclusions, but I don't think this little factoid is worth all that extra work.  However, feel free to play with the code yourself--attached are two solutions.  One produces a signed class library and the other is a WAP that references the DLL produced by the first solution.  Build that class library, put it in the GAC, delete it from the bin directory, then see how the WAP can still build successfully.

GACRefTest.zip (332.83 kb)

You can't do sufficient .NET development without going to the command line at some point.  Not every tool that you need can be found or worked from the IDE.  There are too many tools to mention (at least in this post) and they tend to change from Visual Studio release to Visual Studio release, but if you're interested, I would recommend starting with Mike Wood's series of posts on Visual Studio 2005 SDK tools: part 1, part 2, and part 3.

Most of the time when working with these utilities, you need to navigate to a particular directory and work on a particular file.  And, of course, it's not enough to open the vanilla command shell (cmd.exe), because the paths to the .NET utilities haven't been mapped in the vanilla shell.  You could open your Start Menu, navigate to the Visual Studio 200X folder and somewhere within that folder launch the shortcut to the Visual Studio 200X Command Shell; then, at that command prompt navigate to the folder and file you want to work...and 50 keyboard clicks later actually start doing your work. That's lame.

Well, some time ago, the effervescent Scott Hanselman offered up a neat little power toy for adding a Visual Studio 200X Command Prompt Here context menu option when you right-click any folder in Windows Explorer.

Scott offered solutions for Visual Studio 2003 and 2005; however, lately, I've been doing a fair amount of work in Visual Studio 2008.  Where is my power toy for that?  Having found no other offerings for such a power toy for 2008, I decided to make my own.  So, I took Scott's solution and carefully and meticulously replaced all the 5s with 8s.  Yes, sheer brilliance, I know.  Well, it was slightly more complicated than that: you do have to change the filepath to the place where vsvars32.bat lives within your Visual Studio 2008 install, but other than that, it was a pretty simple modification.

I don't know much about the INF extension, but I do like the fact that it registers the power toy in the Add/Remove Programs control panel.  That's nice, because should you mess up modifying the INF file, you can always remove it and start over.  I've attached my INF file to this post.

 

vsnet2008cmdhere.inf (1.49 kb)