Answered by:
System Environment Variable in Post-Build Error

Question
-
Here’s the problem:
I sometimes use system environment variables in the post build event in C#. For example:
copy $(TargetPath) "%CopyPath%$(TargetFileName)"
This works great in VS 2003. It also works fine for projects which I have auto-converted from VS 2003 to VS 2005. However, for projects which I initiated in VS 2005, it does not work. The “%” symbols do not result in an interpretation of the system environment variable. Instead, I get this error (fake paths substituted for security):
“Error1 The command "copy C:\MyProj\MyProj\bin\Debug\MyProj.dll "%CopyPath%MyProj.dll"" exited with code 1 MyProj”
Here’s the really weird part. Just to be sure no typos or hidden characters were involved… If I copy the same post-build event that is failing in the VS 2005 initiated project into a VS 2005 project which was converted to VS 2003, it works fine! On the other hand, if I copy a post-build event that is succeeding in the converted project back into the VS 2005 initiated project, it fails! (Checking the project files in Notepad, the build event lines compare exactly.)
I figured the difference must lie somewhere in either the project or configuration settings, but I can’t seem to find it. (And yeah, I Googled the heck out of it, :lol: ) Any ideas?
-Neil
Saturday, November 25, 2006 3:39 PM
Answers
-
Hi Dan,
First of all, thanks for your reply. I had found the escape sequence idea on my own by trial and error and tried that with no success. However, I found the problem and it turns out to have been much simpler!
Things start to work if I restart VS2005 whenever I change the value of an environment variable I'm using. I guess something is being cached somewhere. Since I have at least one copy of VS2005 running most of the time, I never even thought to do a complete restart on the entire product. (I feel like I live inside VS sometimes, lol.) In that context, probably something about the particular environment variable I was using was causing the command shell to return an error instead of just interpreting it as "..\" or something else incorrect but innocuous.
Anyway, thanks again for taking a look at it.
-Neil
Friday, December 1, 2006 4:08 PM
All replies
-
MSBuild projects don't recognize %xxx% syntax. To refer to environment variables, like any other properties, you can use the $(xxx) syntax.
The exception is in strings that ultimately get executed with an Exec task -- like pre and post build events. After $(xxx) expressions are expanded, these will go to cmd.exe, which is quite happy with %yyy% syntax. So I would expect either to work in such cases.
The difference could be related to whether you're typing the % characters in the project property pages in VS, or directly into the project file (eg., with notepad). When you go through VS, VS knows that % is a special escaping character for MSBuild, and escapes it. That could be related.
I suggest that you open the project file directly in notepad and use the $(xxx) syntax.
Dan
Thursday, November 30, 2006 12:48 AM -
Hi Dan,
First of all, thanks for your reply. I had found the escape sequence idea on my own by trial and error and tried that with no success. However, I found the problem and it turns out to have been much simpler!
Things start to work if I restart VS2005 whenever I change the value of an environment variable I'm using. I guess something is being cached somewhere. Since I have at least one copy of VS2005 running most of the time, I never even thought to do a complete restart on the entire product. (I feel like I live inside VS sometimes, lol.) In that context, probably something about the particular environment variable I was using was causing the command shell to return an error instead of just interpreting it as "..\" or something else incorrect but innocuous.
Anyway, thanks again for taking a look at it.
-Neil
Friday, December 1, 2006 4:08 PM -
Changing the environment variables in a shell, or globally in computer properties, doesn't change the set used in an existing process, if that's what you mean. Anyway, glad you're set .
Dan
Friday, December 1, 2006 7:50 PM