|
Thanks for putting my explanation into much better terms. I’ve been thinking on this a little more, and I’ve
decided that every compiler and linker is probably at the mercy of Visual
Studio’s environment variables. This can’t be a bug in candle.exe,
but more of the way Visual Studio handles paths. Thanks again! Joel Peterson From: Cullen Waters
[mailto:[EMAIL PROTECTED] Joel,
I think you may be seeing the difference between user scope environment variables,
and system scope env variables. When you set a user-scope variable, it is
set in the instance of cmd.exe that is executing. If you set a
system-scope variable, it isn’t re-read until you kill and restart
cmd.exe.
I’m not sure how VS treats it, but based on the behavior you’re
seeing, I would guess that VS keeps an instance of cmd.exe alive (with console
redirected back to VS). When you set the system-scope variable, VS
isn’t aware of it until you cause the cmd.exe to be reloaded (by closing
and re-opening VS).
I’m not an expert on these issues, but that is what I think you’re
seeing. Cullen From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Peterson,
Joel Hi all. I know that when you open cmd.exe, it loads all of the
environment variables and caches them. If you were to navigate to System ->
Advanced -> Environment Variables and add a new System variable named
“testvar”, typing “cd %testvar%” in the existing
cmd.exe wouldn’t work. You’d need to open a new cmd.exe instance
for it to know about the new environment variable. This doesn’t seem be to true for candle.exe, which I
assume uses what Visual Studio 2005 caches from Environment Variables when it
starts. I was working on a project and wanted all of my File sources to inherit
from a parent directory that will be different on the Team Foundation Build
system and developer workstations. Leaving Visual Studio 2005 open, I created a
new Environment Variable named “BuildPath” with the value
“C:\Build”. I then referenced this path for each File in my .WXS, for
example: <File Id=”test.exe”
Name=”test.exe” KeyPath=”yes”
Source=”$(env.BuildPath)\TestFolder\test.exe” /> Upon pressing F7 (Build Solution), it returns the error
“Error CNDL0150: Undefined preprocessor variable
‘$(env.BuildPath)’.” On a hunch I closed Visual Studio 2005,
opened the Solution, and pressed F7 again to it have it work perfectly. I’m having a hard time understanding why this would be
different from my cmd.exe example, if each time I press F7 (Build Solution), a
new instance of candle.exe is starting. I’m not familiar with all of the
nuances of Visual Studio; is it standard for compilers and linkers to use
environment variables cached by Visual Studio? If not, should I file this as a
bug? Thank you. Joel Peterson |
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
