views:

22

answers:

1

What reasons could there be for the following strange behaviour, and how might I track down the issues?

We use a combination of make files and msbuild.

I have a project which needs to be strongly named. I was previously setting the snk to use in the project file like this:

<AssemblyOriginatorKeyFile>$(EnvironmentVariable)TheKeyName.snk</AssemblyOriginatorKeyFile> 

where EnvironmentVariable was defined in the batch file that launched the shell for the build like this:

set EnvironmentVariable='SomePath'

and this worked ok. Now I need the string name key to be able to be changed, so it can be different on the dev machine and the release build server. There is a variable which exists to hold the full path to the strong name key file, called StrongNameKeyFile. This is defined in the msbuild environment, and if I put some text output in the targets or properties files that are included as part of the msbuild task which build the project then I can see that this StrongNameKeyFile points to the correct location. So I changed the csproj to have this instead:

<AssemblyOriginatorKeyFile>$(StrongNameKeyFile)</AssemblyOriginatorKeyFile>

but when I try and compile this is evaluating to empty and no /keyfile is specified during the build.

We also have variable defined in the make files and these can be accessed in the csproj as well. These are used to point to the locations of referenced dlls, so that they can be different on dev and build machines. I know that these are set as the references come out correctly and everything compiles, but if I try and use one of these variables in the AssemblyOriginatorKeyFile element then it evaluates to empty in that element, but works in the reference element.

Why might this be? Is AssemblyOriginatorKeyFile treated specially somehow? How can I go about tracking the cause of this down?

+1  A: 

There's no good reason why this should happen - as you know it normally Just Works; it's likely to be something in the chain dropping it on the floor.

One thing to try is explicitly passing it via /p:StrongNameKeyFile=XX - that would eliminate environment variables and the correct propagation thereof from your inquiries.

Another potential thing is that something is clobbering the variable as the name is used vy something else?

Run with /v:diag and you'll get dumps of all the inputs and/or variables as they change.

Or if on V4, use the MSBuild Debugger

And buy the Hashimi et al MSBuild book

Ruben Bartelink
thanks, the /v:diag might be just what I am looking for. I'll try that ASAP.
Sam Holder