MSBuild Team Blog : Neil Enns

Why are build numbers limited to 65535?

msbuild — Wed, 03 Jan 2007 21:40:00 GMT

In my previous post I explained how to fix the issue with the default date format provided in the AssemblyVersionTask. Several people encountered the problem with the arrival of 2007, and all of them sent me mail about it :) After providing them with the fix, a few people wrote back and commented (with variying degrees of politeness) that my code was bad and that I should change it to support a larger build number.

That's a mighty fine suggestion, but unfortunately the limitation isn't in my code, it's imposed by the operating system:

Binary version number for the file. The version consists of two 32-bit integers, defined by four 16-bit integers. For example, "FILEVERSION 3,10,0,61" is translated into two doublewords: 0x0003000a and 0x0000003d, in that order. Therefore, if version is defined by the DWORD values dw1 and dw2, they need to appear in the FILEVERSION statement as follows: HIWORD(dw1), LOWORD(dw1), HIWORD(dw2), LOWORD(dw2).

So, I'm sad to say, we will be stuck with 16-bit build numbers forever.

[ Author: Neil Enns ]

Fixing invalid version number problems with the AssemblyInfoTask

msbuild — Wed, 03 Jan 2007 21:33:00 GMT

The arrival of 2007 bought a flurry of e-mails to the MSBuild team from people having trouble with the AssemblyInfoTask. The symptom is simple to describe - the builds start to fail with the following error:

Error emitting 'System.Reflection.AssemblyVersionAttribute' attribute -- 'The version specified '1.0.70102.1' is invalid

The fix to get builds going again is to change the date format used to generate the build number to something other than the default "yyMMdd". The date formats are in Microsoft.VersionNumber.target, located in %program files%\MSBuild\Microsoft\AssemblyInfoTask, and there are two of them (one for file version and one for assembly version). You can use any format you want. Within Visual Studio we're now using 01MMdd.

Note that you may have to go in and hand-edit your assemblyinfo.* files to change their version number back to a default starting point of 1.0.0.0 to get your builds going again.

Questions or problems after doing the above? Contact us using the e-mail link at the top of this page.

[ Author: Neil Enns ]

Hotfix is Now Available for Warning C4945

msbuild — Tue, 11 Jul 2006 01:15:00 GMT

If you've been reading our forums you may have seen the long-running thread regarding warning C4945 slowing down certain types of builds. This issue was also reported through our Connect feedback center as issue 123509.

I'm pleased to announce that we have a hotfix available for this problem, and that it's now available through our product support services. To obtain the hotfix you should contact your local product support office and ask for the hotfix in KB article 922271. You should only request this hotfix if you have seen this specific issue, as it will not address or change anything else other than this one specific problem.

Note that if you look for this KB article in our knowledge base database you likely won't see it. Don't worry, that's because we're still writing the actual article and it won't be out for a couple of weeks. The hotfix is available, however, and your product support contact should be able to it without issue.

[ Author: Neil Enns ]

A New Tool For Visually Editing Build Process

msbuild — Wed, 07 Jun 2006 00:08:00 GMT

Eugene sent us mail today to let us know that his company has released a neato little freeware tool to visually edit MSBuild files. A quick glance at the website shows an impressive list of features for v1:

Load and modify any file complying to MSBuild schema
View build project structure in a tree view that displays tasks used in build, property groups and properties, item groups and items, targets and targets tasks and imported build projects.
Show or hide presentation of imported definitions in a project tree view
View MSBuild project raw XML source as you modify the project
Modify project default targets
Add or remove tasks used in build project from external assembly
Add, remove or modify property groups
Add, remove or modify properties in property groups
Add, remove or modify item groups
Add, remove or modify items in item groups
Add, remove or modify targets
Add, remove or modify selected target's tasks, tasks order
Modify selected task properties (including output properties specification)
Import or remove external build projects
Open any imported project from the loaded project

Nicely done guys!

[ Author: Neil Enns ]

What Does This MSBuild Snippet Do?

msbuild — Thu, 18 May 2006 20:35:00 GMT

It's been a while since we've had a little quiz on MSBuild.

Over the last couple of days the MSBuild team has been enjoying working up solutions to a question over in our forums. Last night Faisal and Jeff concoted some MSBuild script that, to be honest, made my head turn sideways and then inside out.

Given the following MSBuild file, what is the output of the build?

No running this on the command-line to find out! That'd be cheating :) See if you can figure it out in your noggin first, and then post your thoughts.

[ Author: Neil Enns ]

MSBuild Extras - Toolkit for .NET 1.1 ships!

msbuild — Thu, 18 May 2006 00:46:00 GMT

It's been a little while (understatement!) since we've blogged something, but today we've got a good one for you.

The MSBuild Extras - Toolkit for .NET 1.1 (a.k.a. MSBee) shipped today!

You can download it at Codeplex. Enjoy!

[ Author: Neil Enns ]

How To: Remove the Up-To-Date Check From the AssemblyInfoTask

msbuild — Tue, 28 Mar 2006 23:57:00 GMT

Every couple of weeks I get mail from someone who is using the AssemblyInfoTask on a build machine under source control. The question typically goes like this:

I added the .targets file to my project, and it works fine on my dev machine, but doesn't do anything when I'm running it in the build lab. What's wrong? Help!

The reason it "doesn't do anything" is because the default Microsoft.VersionNumber.Targets file includes MSBuild attributes that instruct the build engine to check timestamps on input and output files. These were added because it doesn't make much sense to increment the version number on an assembly if nothing is gettting re-built. This can happen if MSBuild does an incremental build on the project.

In the build lab, however, all of the input files (.cs files, generally) and the output file (assemblyinfo.cs) wind up with the same timestamps when they are synchronized from the soruce code control server.

To resolve this, simply remove the Inputs and Outputs attributes from the <Target> tag in the Microsoft.VersionNumber.Targets file. It should wind up looking like this:

[ Author: Neil Enns ]

Beta 2 of the MSBuild Toolkit for .NET Framework v1.1 is Out!

msbuild — Sat, 25 Mar 2006 02:56:00 GMT

Craig just announced over on his blog that Beta 2 is available. New features in this release include:

Support for the ResolveComReference task!
Redirecting the LC task to target .NET 1.1
Defining a FX1_1 constant to let you exclude .NET 2.0 specific code
Providing a BaseFX1_1OutputPath property for replacing the default 'bin\FX1_1' base path.

Enjoy!

[ Author: Neil Enns ]

What Does MSBuild Have to do With The Future of Game Development?

msbuild — Tue, 21 Mar 2006 03:07:00 GMT

Today the folks in our game studios team (XNA) used the Game Developer's Conference to roll out the first major public viewing of what they've been hard at work on. If you want to read about the overall technology preview they released you can look at Michael's blog entry. If you want to see what the press is saying, there are several articles floating around.

"Blah blah blah", I'm sure you're thinking. "Yeah yeah, Microsoft announces some new technology. Biggy dealydo. I'm reading this blog for MSBuild content. Why on earth should I care?"

Ah, but have faith :) It gets very interesting when you dig a little deeper. The CTP includes something called "XNA Build":

Microsoft® XNA™ Build is a tool which will help game studios manage the growing complexities of their game content builds. We invite you to install this pre-release into a non-production environment to learn more about how XNA Build will reduce development complexities.

Michael's blog includes a few more details:

This is the heart of our release at GDC this year. XNA Build is a set of tools that’s designed to help studios with both their code and asset pipelines by providing ways to create, debug, maintain, and optimize those pipelines throughout their studio. XNA Build has really three major components to it, the technology it’s built on, the custom XNA tasks behind it, and the graphical Designer. XNA Build’s underlying technology is powered by MSBuild, a scriptable XML-based build solution that uses pluggable components called “Tasks” to extend the functionality of MSBuild. We have taken the time to construct a set of XNA-specific tasks which facilitate things like dependency tracking, unused file tracking, and analysis using your own custom in-house tools. That’s something that I’d really like you to walk away with: we’re not trying to get you to change or write custom tools to work in our system; we want to work with yours. Finally, there is the Designer. Right now an early prototype, it allows people who aren’t familiar with XML coding or working with batch files to author complex build systems using a drag, drop, and connect methodology.

Wooo, that sounds pretty cool doesn't it? Based on MSBuild? A graphical designer? No wei! Wei!

Got your interest now? Want to see it in action? :) Check out the overview presentation on XNA, as well as the presentation on advanced XNA Build topics.

[ Author: Neil Enns ]

How To: Bypass Post-Build Steps in a Build Lab Environment

msbuild — Sat, 11 Mar 2006 02:06:00 GMT

(Can you tell I'm going through my folder of interesting MSBuild questions today?)

Here's another good question that came across our internal discussion alias last week:

Is there a quick and easy way to bypass the PostBuild steps in a project file that was created with VS.NET 2005? I am trying to set up a master build project that will be compiling a large number of other projects, some that contain PostBuild steps that are not appropriate for our master build. Is there something I can define that will then cause the PostBuild steps to be skipped?

I actually didn't know the answer to this one off the top of my head, but since the entire build process is available for the world to see, it didn't take much to figure it out. I cracked open the Microsoft.Common.Targets file in Visual Studio and looked at how the PostBuildStep is set up. Here's an excerpt from the file:

Notice how the condition is set up. In the build lab, you can simply pass /p:PostBuildEvent="" on the command line to disable all the post build events in the included projects.

[ Author: Neil Enns ]

Why Doesn't Delete Take Wildcards?

msbuild — Fri, 10 Mar 2006 02:01:00 GMT

Here's another question from our internal conversion discussion alias that came through last week:

Does the Delete task in MSBuild not use wildcards? The documentation doesn’t say anything about it but that seems to be the behavior I am seeing. I can always create an ItemList then pass that into delete, but I wanted to verify this was “right”.

The person asking the question is correct: the right way to do this is to create an ItemGroup that contains the list of items you want to delete. Generally you'll do this by specifying each file individually, although you can use a wildcard in the ItemGroup's Include attribute to pick up files as well. You then pass this ItemGroup into the delete task to perform the delete.

Why do we do it this way? We really wanted to ensure people passed around strongly-typed lists of objects through the build process, so things like metadata can flow through the entire build. If you have an individual task like delete take wildcards, people will tend to use the wildcards in the task directly instead of creating a strongly-typed group first.

Of course, sometimes you can't know ahead of time what the item group will be, and that's why we have the CreateItem task (which is, as we've found during the conversion of our internal build process, often required and never very pretty...).

[ Author: Neil Enns ]

How To: Distribute Your Custom Task and .Targets file

msbuild — Thu, 09 Mar 2006 22:38:00 GMT

We've had variations of the same question on how to distribute tasks come through both internal and external channels in the last couple of weeks. Here's one example:

If we have a product that is installing custom MSBuild tasks, are there any type of guidelines on where they should be installed, do they need to be registered, etc.?

The good news is you don't have to register anything at all. You just need to figure out what the best directory is to install your goo. Typically there's two pieces of goo that need to be installed: the assembly with the task(s) in it, and the .targets file that includes a <UsingTask>, assorted properties, and perhaps even a target override.

It turns out that you'll probably want your installer to offer the user the choice of two installation points: one for installing your new MSBuild magic on a developer's machine, and another for installing it in some sort of build-lab environment. Here's a little table with the suggested installation locations:

	Developer Machine	Build Lab
Assembly	Global Assembly Cache	Location of user's choosing
.Targets File	$(MSBuildExtensionsPath)	Location of user's choosing

This requires your setup to actually have two different .targets files, since the <UsingTask> will be different depending on where the task assembly is installed.

To see all this in action I suggest downloading the AssemblyInfoTask sources. It includes a setup project that gives the user of installing the assembly into either the GAC or to their local application data folder. This could be extended to allow installation to GAC or a folder of the user's choosing.

[ Author: Neil Enns ]

MSBuild.GlobalEngine vs "new Engine()": What's the Difference?

msbuild — Thu, 09 Mar 2006 02:30:00 GMT

Earlier this week we got the following question from one of our VSIP partners:

What is the difference between using MSBuild.GlobalEngine or “new Engine()” to build a project programmatically?

I actually never knew there were two ways to do this. Thankfully Rajeev not only knew there were, but knew what the difference was. His response also provides another glimpse into how Visual Studio and MSBuild interoperate:

Engine.GlobalEngine is just an instance of the Engine that was also created with "new Engine()", and the only point of it is so that multiple project systems in the same process (e.g., devenv.exe) can easily share the same engine object. The benefit in all the project systems sharing the same Engine object comes when you have project-to-project references between the various projects. If project A instantiated its own Engine object instead of using GlobalEngine, and it had a P2P reference to Project B, then Project A would end up loading a fresh copy of Project B from disk, instead of using the copy that was probably already loaded by the IDE as part of a different Engine object.

The main point is that projects in different Engine objects cannot talk to each other. So if you want projects to be able to talk to each other, it's best to have them part of the same Engine object, and the easiest way to do that for a VS package is to use the GlobalEngine.

[ Author: Neil Enns ]

How To: Exclude Multiple Files From a Wildcard

msbuild — Thu, 09 Mar 2006 01:56:00 GMT

We got the following question on our internal conversion discussion alias today:

Is there a way to exclude two or more items from an ItemGroup using the “exclude” attribute without using a wildcard?

It turns out the way to do this wasn't clear from our existing MSDN Documentation. Brett, our documentation writer, has a fix in the queue for the next MSDN refresh, but in the mean time here is the answer from Dan:

</ItemGroup>

[ Author: Neil Enns ]

Wildcard Expansion in Project Files

msbuild — Wed, 22 Feb 2006 22:08:00 GMT

We got a question today on our internal discussion alias about the behaviour of wildcard expansions in project files. It went roughly like this:

I have the following target declared in my project file:

<Target Name="MyTarget" Inputs="$(MyInputs)" Outputs="$(MyOutputDirectory)\*">

However, when I build I get the following output:

Output file "d:\Sources\*" does not exist.

Why?

This is because of how wildcards are processed by the MSBuild engine. Rajeev replied with the list of where wildcards are expanded:

The Include attribute of a statically declared item: <MyItem Include="*.txt" />
The Exclude attribute of a statically declared item: <MyItem Include="*.txt" Exclude="a*.txt"/>
The Include attribute of the CreateItem task: <CreateItem Include="*.txt"/>
The Exclude attribute of the CreateItem task: <CreateItem Include="*.txt" Exclude="a*.txt"/>

Do do what the original poster wants you have to create an itemgroup first that has the wildcard in it, and then use that itemgroup as the parameter to the Output attribute.

Jeff replied a second time to the thread to provide more background on why it works this way:

Target outputs are useful to MSBuild when deciding whether or not a Target is up to date and hence whether or not it should be built. MSBuild decides a Target is up to date if each of the files in the Outputs list is newer than each of the files in the Inputs list. In particular, if any file in the Outputs list does not exist, the Target is built.

Of course, a wildcard will always describe exactly what’s on disk when it’s evaluated - rather than what should be on disk once the Target has executed. If we supported wildcards in the actual targets input and output tags this would break the up to date check.

Consider this example:

Inputs=x.cs,y.cs,z.cs, each with file change times of 1/1/2000 12:00
Outputs=x.pdb, with file change times of 1/1/2001 12:00 (constructed with a wildcard in the output tag if we supported it)

Now if x.dll is produced by this target, but had been deleted from disk, MSBuild would mistakenly skip this target because the wildcard didn’t include it and each of the files the wildcard included are coincidentally newer than those in the inputs...

Now you know :)

[ Author: Neil Enns ]