Handling msbuild File Paths in Visual Studio Project Files

Yesterday, a co-worker of mine and I were working on a task which required that we work in the xml of a Visual Studio project file. We were setting up a target with an exec statement, and ran into a little annoyance. The file we were trying to execute was in a folder with a space in the name.

If we were typing this into a command prompt window it would be easy. We would simply wrap the statement in quotes. Working in the project file our brains sort of stopped working. We tried to find a way to escape the spaces in the file path. Instead of doing this in the end we used the xml encoding for a quote. We used " to wrap the path in quotes. Yipee everything worked!

Today we were doing some similar work, and ran into another problem in these files. We want our msbuild stuff to work with both 32-bit and 64-bit machines. The code we are calling is always 32-bit, so we need to use a different file path depending on which type of machine we are using. We found this post on stack overflow from a person who found a way to specify the 32bit directory for program files in msbuild. The post on there is asking for a better solution, so I will also ask people to provide a better solution.

This is how Wimmel solved the problem.

<PropertyGroup>
  <ProgramFiles32 
    Condition="Exists('$(PROGRAMFILES) (x86)')">$(PROGRAMFILES) (x86)</ProgramFiles32>
  <ProgramFiles32 
    Condition="$(ProgramFiles32) == ''">$(PROGRAMFILES)</ProgramFiles32>
</PropertyGroup>

<Exec WorkingDirectory="src\app1" 
  Command='"$(ProgramFiles32)\doxygen\bin\doxygen" Doxyfile' />

All he did is create a variable called ProgramFiles32 which would contain one of two file paths depending on whether the (x86) program files exists. He then uses that variable in his file path. It works reasonably well, and since I am not concerned with running this in any language other than English I am not too concerned with any problems which might arise from this. If this bites me down the road please point me back to this blog post.

Comments