The build engine for Visual Studio is MSBuild. In MSBuild environment variables are accessed just like properties. The build event macros are defined as properties wix2010.targets. That's where your name collision comes in. One of the attributes that gets set on the Light MSBuild task is WixProjectFile which is set to $(ProjectPath) in wix2010.targets.
The source code for the Light MSBuild task shows that the -wixprojectfile argument is appended to the command line only if WixProjectFile is NOT null. Ironically, I expected WixProjectFile to always have a value because ProjectPath is defined as follows <ProjectFileName Condition=" '$(ProjectFileName)' == '' ">$(MSBuildProjectFile)</ProjectFileName> <ProjectDir Condition=" '$(ProjectDir)' == '' ">$(MSBuildProjectDirectory)\</ProjectDir> <ProjectPath Condition=" '$(ProjectPath)' == '' ">$(ProjectDir)$(ProjectFileName)</ProjectPath> The MSBuildProjectFile and MSBuildProjectDirectory properties are reserved properties set by MSBuild automatically. I expected that unless ProjectFileName and ProjectDir were set explicitly to nothing, then ProjectPath should be set to $(MSBuildProjectDirectory)\$(MSBuildProjectFile) which should always resolve to a value. In any case, because MSBuild exposes environment variables just like regular properties you should avoid setting environment variables that match properties used by wix2010.targets like the build event macros. On Sun, Jul 21, 2013 at 8:47 AM, Andreas Jönsson < andreas.jons...@noventus.se> wrote: > Thanks for the reply but I'm not sure if I understand you correctly. Why > would the value of an environment variable called ProjectPath influence > Visual Studio's build event macro $(ProjectPath)? > > I also can't find any reference to either ProjectPath or $(ProjectPath) > in the WiX project files so I don't see why anything is expanded at all. > If I remove the environment variable ProjectPath, the generated command > line becomes just: > > "... -wixprojectfile obj\Release\Product.wixobj" > > I.e the build event macro $(ProjectPath) is not getting expanded. > > > Those properties are build event macros > (http://msdn.microsoft.com/library/42x5kfw4.aspx) and are thus reserved. > > > > > Date: Sat, 20 Jul 2013 21:35:12 +0200 > > > From: andreas.jonsson@... > > > To: wix-users@... > > > Subject: [WiX-users] Environment variable "ProjectPath" is > expanded, possible to turn off? > > > > > > Hello, > > > > > > We have converted one of our installer projects to WiX and it seems to > > > work well. However, on our development machines we have an environment > > > variable, ProjectPath, which is completely unrelated to WiX. When the > > > project is built from Visual Studio (2012), this environment > variable is > > > expanded in Light's command line: > > > > > > 1> C:\Program Files (x86)\WiX Toolset v3.7\bin\Light.exe -out > > > > > C:\BUILD\tools\BuildMgr\trunk\Nov.BuildMgr.WixInstall\bin\Release\BuildmanagerSetup.msi > > > > -pdbout > > > > > C:\BUILD\tools\BuildMgr\trunk\Nov.BuildMgr.WixInstall\bin\Release\BuildmanagerSetup.wixpdb > > > > -cultures:null -ext "C:\Program Files (x86)\WiX Toolset > > > v3.7\bin\\WixUIExtension.dll" -contentsfile > > > > obj\Release\Nov.BuildMgr.WixInstall.wixproj.BindContentsFileListnull.txt > > > -outputsfile > > > > obj\Release\Nov.BuildMgr.WixInstall.wixproj.BindOutputsFileListnull.txt > > > -builtoutputsfile > > > > > obj\Release\Nov.BuildMgr.WixInstall.wixproj.BindBuiltOutputsFileListnull.txt > > > > -wixprojectfile \\DEUS\COMMON\PROJECT obj\Release\Product.wixobj > > > 1>light.exe(0,0): error LGHT0281: The -wixprojectfile option > requires a > > > file, but the provided path is a directory: \\DEUS\COMMON\PROJECT > > > > > > The offending part is "-wixprojectfile \\DEUS\COMMON\PROJECT > > > obj\Release\Product.wixobj" (I have ProjectPath set to > > > \\DEUS\COMMON\PROJECT). The current work-around is to remove the > > > environment variable when building an install project, but this is > a bit > > > clunky. Is there a better solution? > > > > > > Andreas Jönsson > > > > > > > > ------------------------------------------------------------------------------ > > > See everything from the browser to the database with AppDynamics > > > Get end-to-end visibility with application monitoring from AppDynamics > > > Isolate bottlenecks and diagnose root cause in seconds. > > > Start your free trial of AppDynamics Pro today! > > > > > > _______________________________________________ > > > WiX-users mailing list > > > WiX-users@... > > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- Edwin G. Castro ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
