locked
System Environment Variable in Post-Build Error RRS feed

  • 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