views:

184

answers:

2

Hi,

I have a .NET solution containing following projects:

  • web application (WAP)
  • web deployment (WDP, .wdproj)
  • wix setup (WIX, .wixproj)

In the WDP I've used a custom MSBuild task (SetEnvVar) to set some env. variables for further use in the build process. After setting them I can use them without prob. in the WDP but in the WIX they are empty/undefined. The strange thing is that when I reference those env. vars in the WIX files (by using properties in .wxs or preproc vars in .wxi) I get the values as expected.

Do you have any idea why the env. vars get lost/are undefined in .wixproj?

By the way the (solution) build process is triggered from inside VS 2010.

Update

This is basically my task code:

Environment.SetEnvironmentVariable(this.Variable, this.Value);

Is a MSBuild solution build not one process?

Will MSBuild spawn a new process for every project in the solution?

+1  A: 

is it possible your SetEnvVar task sets the environment variables for a single process instead of globally (which it should do to be safe btw)? In that case, it's likely that the WIX thingie is started as a different process in some way, so with it's own private copy of the current global environment set.

stijn
By "globally" you maybe mean using the 2nd SetEnvironmentVariable() overload and setting the 3rd param (Target) to User/Machine?Actually I don't want the env. vars to be persisted in the registry, I only need them during the entire MSBuild solution build process.
DotNetter
With the 3rd param you can set it globally, however it's indeed best practice not to do that as it affects the entire system.Could you run your build with verbose information? I really suspect a part of the build is spawned as a different process which does not inherit environment. By showing diagnostic information you can figure out where this happens, and maybe find a way to pass the environment.
stijn
Thx for the hint, I'll try that.
DotNetter
I can't find anything wrong or useful in the diag info. The env vars are set in the AfterBuild target (also tried BeforeBuild) of WDP and are empty later on in the AfterBuild target of WIX.
DotNetter
My conclusion is these projects must be built by MSBuild in different processes thus my env vars run out of scope after WDP build finished. Why can I reference/use the vars in the WIX files though???
DotNetter
can you post the relevant part(s) of the msbuild project file? It's definitely an interesting problem..
stijn
A: 

Here are the significant parts of the project files:

WDP (.wdproj)

<Target Name="AfterBuild">
    <SetEnvVar Variable="MAJOR" Value="$(MajorNumber)" />
    <SetEnvVar Variable="MINOR" Value="$(MinorNumber)" />
    <SetEnvVar Variable="REVISION" Value="$(RevisionNumber)" />
    <SetEnvVar Variable="BUILD" Value="$(BuildNumber)" />        
</Target>

WIX (.wixproj)

<Target Name="AfterBuild">
    <Message Text="Major: $(MAJOR) Minor: $(MINOR) Revision: $(REVISION)" />
    <Move SourceFiles=".\bin\$(Configuration)\$(OutputName).msi" DestinationFiles=".\bin\$(Configuration)\Product_$(MAJOR).$(MINOR).$(REVISION).msi" />        
</Target>

The Message task's log output is "Major: Minor: Revision: " therefore MAJOR, MINOR and REVISION vars are not availabe to the WIX project and for that the MSI package name is Product_...msi.

The project build order is of course WAP -> WDP -> WIX.

DotNetter
looks fine; only thing I can think of is that VisualStudio spawns 1 msbuild process for each of your project files.. Can you check this, eg in Task Manager?
stijn