How can you access the Visual Studio solution level platform from a C# project's build event?

Question

We have a large VS 2010 solution that is mostly C# code but there are a few native DLLs that various C# projects depend upon (including our unit testing DLL). We're in the processing of trying to support both 32-bit and 64-bit versions of our libraries. So we're now build the native DLLs as 32-bit and 64-bit. The problem is that a lot of our C# project's have post-build events that copy the required native DLLs into the project's TargetDir. Now that we have two different versions of the native DLLs (32 and 64 bit), I need to be able to specify the correct dir to copy the native DLL from. I originally thought I could simply use $(Platform) in the path like so:

copy $(SolutionDir)\NativeDll\$(Platform)\$(Configuration) $(TargetDir)

But that doesn't work because $(Platform) is the project's platform and not the solution level platform. In this case $(Platform) is "Any CPU". From what I can see looking at the post-build event macros in C# project, there doesn't appear to be a way to access the solution level platform that is being built. Is there a better way to accomplish my goal?

Answer 1

I believe the solution's platform, unlike that of the projects is simply text.

What I have down in the past is:

1. Delete Win32 and "mixed platform" from solution (and keep doing so after adding projects).

2. Set all C# DLLs to build as AnyCPU in solution platforms AnyCPU, x86, x64. (Do not delete AnyCPU if you want to be able to open in Blend or if you have any pure managed applications in the solution.)

3. Set C# EXEs and unit tests to build in x86 in x86 solution platform and x64 in x64 solution platform and not to build at all in AnyCPU solution platform.

4. Set all natives to build in Win32 when solution is x86 and output to $(ProjectDir)\bin\x86\$(Configuration) and intermediate to same with obj in path instead of bin. x64 the same with x64 instead of x86 and Win32.

5. Set pre build events of C# EXEs and unit tests to copy native DLLs they are depended on from relative path with project's configuration name: $(Config)

6. Set unit tests' class initialize to copy entire contents of tests bin dir (correct platform and configuration, of course) to tests' out dir. Use if #DEBUG and unsafe sizeof(IntPtr) to tell where to look for tests' bin dir.

7. Manually (using Notepad) add relative reference path to .csproj files outside solution that use x86/x64 assemblies from solution's deployment location, so path will include $(Platform) and $(Configuration) and will not be per user.

Microsoft: Better 32/64 bit support in Visual Studio would be really in place.

Answer 2

When I had to do this, I simply made all of my assemblies buildable as x86 or x64 rather than AnyCPU, and had two separate output packages. There's really no point in AnyCPU if you KNOW your process must be 32-bit or 64-bit a prori.

Answer 3

I've not used it myself, but Build -> Batch Build is probably what you want. With it you can build multiple platforms.

http://msdn.microsoft.com/en-us/library/169az28z.aspx

Of course, this doesn't actually enable you to access the 'platform' for the solution, but you don't need to since you'll build each platform separately.

Update: If you want to automate the build, create a batch file with the following contents

"c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv" ../solution.sln /rebuild "platform"

where 'platform' is "Release|Any CPU", "Release|x86" etc. and repeat the line for each configuration you need to build. Use the Configuration Manager to set up each project for a a build for x86 and x64 and you should have what you want.

Answer 4

I don't think the 'Active Solution Configuration' has an equivalent macro property.

What I suggest is to manually add a custom property in all .csproj files, like this (see the new MyVar custom property added for each configuration/platform combination):

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  ...
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
    ...
    <MyVar>MyDebugAnyCpu</MyVar>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
    ...
    <MyVar>MyReleaseAnyCpu</MyVar>
  </PropertyGroup>

You can use the 'Unload project' and 'Edit MyProject.csproj' menus to edit the .csprojet whil in Visual Studio. What's important to know is Visual Studio will not destroy these 'unknown' values even if you save it using the normal GUI editor.

Then in the post build event, you can use these values, for example:

copy $(SolutionDir)\$(MyVar)\$(Platform)\$(Configuration) $(TargetDir)

Answer 5

Francesco Pretto has an extension that helps with this. It seems to have some quirks and deficiencies, but it's a start.

http://visualstudiogallery.msdn.microsoft.com/619d92a2-4ead-410d-a105-135f7b4b4df9

With source on github:

https://github.com/ceztko/SolutionConfigurationName