MSBuild Team Blog : Known Issues

Manifest resource names changed for .resources files

msbuild — Fri, 19 Oct 2007 21:34:00 GMT

Juergen Bayer notified us of an issue introduced in MSBuild in .NET 3.5 "Orcas". The problem is if you have any items of type EmbeddedResource in your project file that are actually .resources format, rather than the usual .resx. In other words, for some reason you have already converted them from human-readable form. We believe the impact should not be widespread since usually projects use .resx files. Plus, "Orcas" is essentially locked down at this point, so it's too late to fix it for this release.

When we embed a resource in an assembly, we pick a name for the stream. This name is fairly unimportant, as long as it's distinct and consistent. Its only purpose is to specify the stream your resource manager should read. In VS2003, VS2005, through .NET 2.0 SP1, the stream name for .resources itself ended with the .resources extension. In VS2008/.NET 3.5, we inadvertently broke this: it no longer has .resources on the end. The effect will be at runtime your resources will not load properly. The workaround (apart from changing to use .resx instead which we will create .resources from for you) is to add a Logical Name metadata to the affected resources to specify the correct name, something like this:

    <EmbeddedResource Include="Resources\Images.resources" >
       <LogicalName>$(RootNamespace).Resources.Images.resources</LogicalName>
    </EmbeddedResource>

Of course, the names we pick for streams originating in .resx files did not get changed.

Dan

Multitargeting against .NET 2.0

msbuild — Tue, 09 Oct 2007 23:57:00 GMT

If you're using the new VS 2008 multitargeting features to target .NET 2.0 you should be aware that in VS 2008 they have a limitation related to service packs.

In .NET 2.0 SP1, the CLR team has added a few types to existing .NET 2.0 assemblies. For example, DateTimeOffset has been added to mscorlib.dll.

Since VS 2008 installs .NET 2.0 SP1 (sometimes known as "redbits"), with VS 2008 you will be able to successfully build and test an app that uses DateTimeOffset, even if you explicitly tell VS 2008 that you wish to target .NET 2.0. But then if you move this app to a machine that only has the original .NET 2.0 on it, it won't run. This is really a limitation in the Visual Studio multitargeting implementation, at least assuming that the CLR team made the right choice in adding this to an existing assembly.

This limitation may be addressed in the next version of Visual Studio. Meanwhile, if you want your app to work on machines without .NET 2.0 SP1, make sure you verify that it compiles on such a machine. You don't need to install Visual Studio to compile it, of course -- MSBuild 2.0 can do it. If your project was created by Visual Studio 2008, it will use the property $(MSBuildToolsPath) in it, which is new in MSBuild 3.5. Also, Visual Studio 2008 updated the solution version number to something MSBuild 2.0 won’t recognize (that's another story). To work around these issues, specify the project directly, and set a property, like this

%windir%\microsoft.net\framework\v2.0.50727\msbuild.exe /p:msbuildtoolspath=%windir%\microsoft.net\framework\v2.0.50727 myProjectCreatedByVS2008.csproj

If this builds successfully without .NET 2.0 SP1 installed, you’ll know you haven’t used one of these types.

By the way, .NET 2.0 SP1 will be available as a standalone install, or it will automatically be installed when you install .NET 3.5 or Visual Studio 2008, or Vista SP1, or "Longhorn" server.

[Author: Dan]

Update: Scott has generated a libcheck diff showing all the new types in SP1. Take a look here: http://www.hanselman.com/blog/content/binary/org2.0to2.0/APIChangesorg2.0to2.0.html

Also, Krzysztof has created an FXCop rule to check for these changes: http://blogs.msdn.com/kcwalina/archive/2007/10/02/Multi_2D00_TargetingAndFxCop.aspx

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 ]

/p property values are immutable - (sort of)....

msbuild — Thu, 05 Oct 2006 18:55:00 GMT

Hello there - sorry for the long absence, but we're back and hopefully I'll keep this going again.

So there was a recent forum post about how property values that are specified from the command line are immutable - i.e. it is not straightforward to change them from within the project file. Well, this is mostly true, but there are exceptions.

Let's take an example:

If I've got a property in my project file defined like this,

<Configuration>Debug</Configuration>

</PropertyGroup>

then, calling msbuild with /p:Configuration=Release will override this value (or alternatively set the value if it is not defined) for all projects that are being built. Properties that we pass in with a /p switch on the command line are known as "Global Properties" and so it will flow down to all projects that are being built - so if you were building a solution file, all projects will get the overridden value of this property.

Now, let's say that you have this defined in your project file:

<AppPath Condition=" '$(AppPath)' == '' ">bin\debug\</AppPath>

<AppPath Condition=" !HasTrailingSlash('$(AppPath)') ">$(AppPath)\</AppPath>

</PropertyGroup>

What I am doing here is that I am defining a default value for AppPath property if AppPath is not defined. Additionally, I want to set it up so that if someone has specified an AppPath property, then if it does not already have a trailing slash, I'd like to add it. Looks reasonable, correct?

Actually this will not work as you expect - and is something to watch out for. What happens when you specify something with a /p:AppPath=blah\ is that all in-project property definitions for AppPath are ignored (or essentially overridden), and so none of the in-project property definitions take effect - even the ones with the condition. This makes sense if you think about it because otherwise what exactly are we supposed to override? Would that be the first definition of the property? Or should we override only those values of the property that are checking against an empty value? There isn't a clear answer. We override all property definitions and what is passed in is the effective value.

Fortunately, there is a way around this if it causes you grief - but it isn't declarative like PropertyGroup. You have to use the CreateProperty task inside a target where you intend to process the property, like so:

</CreateProperty>

Alternatively (and perhaps as a better approach), you can use a property name like AppPath as the public property you expect to override from th command line, but filter it out into a different property inside your targets that you then use for doing the actual work - like this:

<_validatedAppPath>$(AppPath)</_validatedAppPath>

<_validatedAppPath Condition=" '$(_validatedAppPath)' == '' ">bin\debug\</_validatedAppPath>

<_validatedAppPath Condition=" !HasTrailingSlash('$(_validatedAppPath)') ">$(_validatedAppPath)\</_validatedAppPath>

</PropertyGroup>

In this case, you validate the /p value and store it in an internal property that is validated, and never directly overridden from the command line.

Hope this helps, and clears some confusion on "strange behavior" if you ever encountered it.

[ Author: Faisal Mohamood ]

Well Known Limitation: Dynamic items and properties not emitted until target execution completes

msbuild — Tue, 03 Jan 2006 03:46:00 GMT

Sayed Ibrahim Hashimi has written about a restriction that he ran into when using CreateProperty and CreateItem tasks to dynamically emit properties and items. The issue has to do with not being able to access items and properties that are created within a target until the target execution actually completes.

So, if you were to run CreateProperty or CreateItem and immediately execute the CallTarget task to invoke another target that needed access either an item or property that was just created, you will be out of luck. We don't publish dynamic properties or items until the target that created them is done executing. This is a known issue for Whidbey. Fortunately the workaround is simple: have one target emit the items/properties and finish execution before you run the next target that uses them. You can sequence the execution of these two targets via a DependsOnTargets attribute on a master target - alternatively the master target can use CallTarget to invoke both the targets sequentially.

Thank you Sayed for reporting it via the MSDN Product Feedback Center. We have it on our list of feature items to consider for Orcas, and we will need to either publish items and properties globally even before the target execution completes - or alternatively allow parameter passing into targets.

Feedback and blogging about these topics just gives us a better idea of the pain points our customers are experiencing today. Thanks for the feedback and continue sending us more.

[ Author: Faisal Mohamood ]