The MSBuild Task and Environment Variables

Issue:

During my forays into the MSDN TFS Forums, I came across a question from someone trying to set an environment variable in the build and retrieve it from a called MSBuild task.  A problem arose when the called MSBuild task was seeing the old value of the environment variable instead of the new value.  This perplexed the writer for a bit until a few pieces of information came together to shed some light on what was going on.

Background:

Here's a couple of tidbits that will help to explain this situation:

1. The Windows OS fires a "An Environment Variable Has Changed" event (no, not the real name) when an environment variable is created or changed.
2. When a process starts, Windows gives it a copy of all of the environment variables in force at that moment.
3. When the MSBuild task is invoked from within an MSBuild file, the newly invoked MSBuild is run in the same process space as the existing MSBuild.

What happened:

In this case, what occurred was:

• The initial MSBuild process was created and Windows gave it a copy of the environment variables as they existed at that moment. 
• During the MSBuild run, one of those environment variables was updated to a new value.
• The MSBuild process wasn't written to listen for the "An Environment Variable Has Changed"message, so the change went unnoticed.
• A new MSBuild task was fired within the existing process, so it only had access to the old version of the environment variable. 

The writer wanted the spawned MSBuild to utilize the new environment variable value when it compiled his solution.

Solution/Workaround:

If you have a need invoke MSBuild and have it pick up a recently modified environment variable, you should fire MSBuild.exe with an Exec task.  This will run the spawned MSBuild.exe in its own process, thus getting an updated set of environment variables to play with.

A Microsoft VB 2005 fix that you can't live without!

 

I know that I promised a document that could be used in training developers shifting from VSS to TFS VC, and I'm working on it, but I just found out about a Microsoft patch that everyone needs to hear about.

The symptoms are these:  You have a solution in VB that has a large number of projects.  You have just done a clean "Get" from your favorite source control repository and may be missing some dependent assemblies.  In my case, we don't use project references, but rather favor file references for our dependencies.  Well, when we sync our code to an empty directory structure, none of the binaries that we are referencing exist.  This means that Visual Studio is inundated with errors whining about missing base classes and my favorite, "Class X must support method Y of interface Z." So you fire off a local build and it goes merrily along until it finishes with errors because you forgot to get the  strong-name key.  DOH!  So you get the strong-name key and note with awe that you have around 1,000 errors in the Error List.  You also note that your IDE has been taken to it's digital knees by the overabundance of bugs crawling through it.  At this point your IDE as become the equivalent of that pet rock your had to have when you were a kid (yes, I know, dating myself).  So that's the part that sucks.  Here's the part that's cool.  Microsoft fixed this damn problem and has put out a patch.

Here's the link to the KB article.  I've installed it and followed the directions and now when I get a crap load of bugs in my Error List, I can still get some work done.  I am now more productive and less grumpy.  If you have this problem, you can't do without this patch.

The Blogosphere just got a little bigger...

I’d like to introduce you all to Bernardo Heynemann, the newest member of the Wonderful World of Blogging.  Bernardo is a member of the Vertigo Project  that has just completed work on v0.2 Alpha’s  presentation layer.  His blog contains all manner of great tidbits about TFS, Visual Studio and development in general.  Hopefully he won’t get too sucked into this blogging thing so he’ll have time to devote to Vertigo’s next release (unlike me).

Welcome to the ‘Sphere Bernardo!

 

The Branching Tab in TFS VC Explained

I had written a note to myself to write an article on how to read the Branches tab of a file’s properties, but Martin Woodward beat me to it.  Here is a link to Martin’s discussion.

http://www.woodwardweb.com/vsts/000267.html

Adding the TeamBuild's build number to your binaries

Came across a post from Jeff Atwood (Vertigo Software) showing how to add the Team Build build number string to theAssembly Description property in your AssemblyInfo files.   This is one of those posts that I don’t want to lose, so I’m putting it up here.

http://blogs.vertigosoftware.com/teamsystem/archive/2006/07/06/Adding_the_Build_Number_to_your_binaries.aspx

 

I'm Famous!!!

Just wanted to do a little ego stroking ( and I mean that in the most Christian sense). 

It looks like Buck Hodges was looking up “troublemaker” in MSN Search and found my blog.  He has posted some commentary and links to a few of the “classics” and agrees that overriding CoreCompile is a bad idea.  So thank’s to Buck for the additional exposure and to all 7 of my readers, I’ll be posting more soon (I really mean it this time). 

I’m working on a syllabus/article that I’m using to train our in-house developers moving from VSS to TFS.  It will cover the similarities and differences between the two systems in concepts and actions.  The outline was used to give a 2–hour class to small group of our in-house staff and will be offered to the rest of the developers as they migrate into TFS VC.  I believe that it will be helpful to others making the same journey…stay tuned.

Here’s the link to Buck’s blog: http://blogs.msdn.com/buckh/archive/2006/08/10/core_compile.aspx

– Steve

 

A custom MSBuild task to retrieve a workspace name and owner based on a given local path

UPDATE Jan 26, 2013 - I received a comment that the download link is broken.  When I checked the link URL I realized that the ZIP file was hosted on my old ISP and was never migrated.  I don't have a copy available anywhere, sorry.  I would however recommend that you check out the Community TFS Build Extensions project.

I’m working on hooking my code generation utility MSBuild task into my VB project files. I’ve create a new BuildType called “CodeGenDebug” which I will use in my Continuous Integration build. I’d also like to give my devs the ability to run this build fromthe VS IDE if they have to update a large number of code generated files, say when a core template changes. It all looked good until I noticed that the build from the IDE doesn’t give you the current workspace name as a parameter. This will cause a problem since the code generation utility checks out all of the code gen specific files prior to doing the generation.
My first thought was to just assume that the machine name (which is available) is the workspace name since the default name given to a workspace is the machine name. AllI had to do was mandate that the devs couldn’t have more than 1 workspace and that it had to be named the same as their workstation name. Needless to say, that didn’t go over very well…
So I discussed it with some of the members of my team and happened to mention it to Mike Ruminer, who happens to be hanging around my office this week trying to get us hapless buffoons going with TFS (we aren’t really hapless buffoons, but I’ve been trying to work that phrase into my blog for a month now…maybe I’ll use it at a meeting soon {evil grin}). Anyway, he wondered why I just don’t ask TFS for the workspace name since I have the path available. So I did.
Here is a custom MSBuild task that will give you the workspace name and workspace owner name for a given local path. It will thrown an exception if it can’t find a matching workspace or if the local path isn’t mapped. Look at the included .proj file for the syntax and UsingTask declaration.
Enjoy!
The zip file contains the source code, binaries and a test MSBuild project file.
Download