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

Question

We have a great VS 2010 solution, which is mostly C # code, but there are several native DLLs that various C # projects (including our modular DLL) depend on. We are working on handling support for 32-bit and 64-bit versions of our libraries. So now we are creating our own DLLs, both 32-bit and 64-bit. The problem is that many of our C # projects have post-build events that copy the necessary DLLs to the TargetDir project. Now that we have two different versions of the native DLLs (32 and 64 bits), I need to specify the correct directory for copying the native DLL. Initially, I thought I could just use $ (Platform) in a path like this:

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

But this does not work, because $ (platform) is a project platform, not a solution level platform. In this case, $ (Platform) is "Any processor." From what I see, looking at event macros after assembly in a C # project, there seems to be no way to access the solution level platform that is being built. Is there a better way to achieve my goal?

Answer 1

I believe that a solution platform, unlike projects, is just text.

What I had in the past is:

• Remove Win32 and the “mixed platform" from the solution (and continue to do so after adding projects).

• Define all C # DLLs to build as AnyCPU on AnyCPU, x86, x64 solution platforms. (Do not uninstall AnyCPU if you want to open in Blend or if the solution has any clean, managed applications.)

• Install C # EXE and unit tests to build on x86 on the x86 and x64 solutions platform on the x64 solutions platform, and not on build at all on the AnyCPU solutions platform.

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

• Define C # EXE pre-build events and unit tests to copy your own DLLs, which they depend on the relative path with the project configuration name: $ (Config)

• Initialize the unit tests class to copy the entire contents of the bin dir tests (the correct platform and configuration, of course) to the test files. Use if #DEBUG and unsafe sizeof (IntPtr) to indicate where to look for bin files for tests.

• Manually (using Notepad) add the relative reference path to the .csproj files outside the solution using x86 / x64 assemblies from the solution deployment location, so the path will include $ (Platform) and $ (Configuration) and there will be no user.

Microsoft: The best 32/64 bit support in Visual Studio will really be in place.

Answer 2

When I had to do this, I just made all my builds available as x86 or x64, not AnyCPU, and had two separate output packages. There really is no point in AnyCPU if you KNOW that your process must be 32-bit or 64-bit prori.

Answer 3

I did not use it myself, but Build -> Batch Build, probably you want. With it, you can create multiple platforms.

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

Of course, this actually does not allow you to access the "platform" for the solution, but you do not need it, since you will build each platform separately.

Update: If you want to automate the assembly, 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 the "platform" is "Release | Any CPU", "Release | x86", etc. and repeat the line for each configuration you want to build. Use Configuration Manager to configure each project to build for x86 and x64, and you should have what you want.

Answer 4

I do not think that “Active Solution Configuration” has an equivalent macro property.

I suggest manually adding a custom property to 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 .csprojet, while in Visual Studio. It is important to know that Visual Studio will not destroy these "unknown" values, even if you save them using a regular graphics 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. He seems to have some quirks and flaws, but this is the beginning.

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

With source on github:

https://github.com/ceztko/SolutionConfigurationName