views:

576

answers:

3

I just finished setting up an out-of-place build system for our existing C++ code using inherited property sheets, a feature that seems to be specific to the Visual C++ product. Building out-of-place requires that many of the project settings be changed, and the inherited property sheets allowed me to change all the necessary settings just by attaching a property sheet to the project. I am migrating our team from C++/MFC for UI to C# and WPF, but I need to provide the same out-of-place build functionality, hopefully with the same convenience. I cannot seem to find a way to do this with C# projects - I first looked to see if I could reference an MsBuild targets file, but could not find a way to do this. I know I could just use MsBuild for the whole thing, but that seems more complicated than necessary. Is there a way I can define a macro for a directory and use it in the output path, for example?

A: 

Is there a way I can define a macro for a directory and use it in the output path

Have you looked at the pre-build and post-build events of a project?

John Smithers
A: 

Actually, pre-build and post-build events seem to be solely a place to add batch-file type commands. This would not help me to set up standard build directories for our projects, unfortunately. And having these events create batch files seems like a very 1980's approach for a modern language like C#, IMO.

After digging some more, and experimenting, I have found that you can add an <Import> directive into your .csproj file. When you do this, the IDE pops up a warning dialog that there is an unsafe entry point in your project - but you can ignore this, and you can make it not appear at all by editing a registry entry, evidently. So this would give me a way to get the variables containing the directory paths I need into the .csproj file.

Now to get the Output Path to refer to it - unfortunately when you add a string like "$(MySpecialPath)/Debug" to the Output Path field, and save the project, the $ and () chars are converted to hex, and your file get's put in a Debug directory under a directory named "$(MySpecialPath)". Arrgghh. If you edit the .csproj file in a text editor, you can set this correctly however, and it seems to work as long as the <Import> tag appears before the <PropertyGroup> containing the Output Path.

So I think the solution for me will be to create a standard OurTeam.targets MsBuild file in a standard location, add an installer for changing the registry so it doesn't flag warnings, and then create custom project templates that <Import> this file, and also set the Output Path to use the properties defined in the OurTeam.targets file. Sadly, this is more work and a less elegant solution than the property sheet inheritance mechanism in C++.

Brian Stewart
+3  A: 

I'm not quite sure what an "out-of-place" build system is, but if you just need the ability to copy the compiled files (or other resources) to other directories you can do so by tying into the MSBuild build targets.

In our projects we move the compiled dlls into lib folders and put the files into the proper locations after a build is complete. To do this we've created a custom build .target file that creates the Target's, Property's, and ItemGroup's that we then use to populate our external output folder.

Our custom targets file looks a bit like this:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"&gt;
    <PropertyGroup>
        <ProjectName>TheProject</ProjectName>
        <ProjectDepthPath>..\..\</ProjectDepthPath>
        <ProjectsLibFolder>..\..\lib\</ProjectsLibFolder>

        <LibFolder>$(ProjectsLibFolder)$(ProjectName)\$(Configuration)\</LibFolder>
    </PropertyGroup>

    <Target Name="DeleteLibFiles">
        <Delete Files="@(LibFiles-> '$(ProjectDepthPath)$(LibFolder)%(filename)%(extension)')" TreatErrorsAsWarnings="true" />
    </Target>
    <Target Name="CopyLibFiles">
        <Copy SourceFiles="@(LibFiles)" DestinationFolder="$(ProjectDepthPath)$(LibFolder)" SkipUnchangedFiles="True" />
    </Target>

    <ItemGroup>
        <LibFiles Include=" ">
         <Visible>false</Visible>
        </LibFiles>
    </ItemGroup>
</Project>

The .csproj file in Visual Studio then integrates with this custom target file:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="3.5" ... >
    ...
    <Import Project="..\..\..\..\build\OurBuildTargets.targets" />
      <ItemGroup>
        <LibFiles Include="$(OutputPath)$(AssemblyName).dll">
          <Visible>false</Visible>
        </LibFiles>
      </ItemGroup>
    <Target Name="BeforeClean" DependsOnTargets="DeleteLibFiles" />
    <Target Name="AfterBuild" DependsOnTargets="CopyLibFiles" />
</Project>

In a nutshell, this build script first tells MSBuild to load our custom build script, then adds the compiled file to the LibFiles ItemGroup, and lastly ties our custom build targets, DeleteLibFiles and CopyLibFiles, into the build process. We set this up for each project in our solution so only the files that are updated get deleted/copied and each project is responsible for it's own files (dlls, images, etc).

I hope this helps. I apologize if I misunderstood what you mean by out-of-place build system and this is completely useless to you!

akmad