我们有一个大的VS 2010的解决方案，主要是C＃code，但也有各种C＃项目取决于（其中包括我们的单元测试DLL）中的一些原生的DLL。我们在试图同时支持32位和64位版本，我们图书馆的处理。所以，我们现在建立了本地的DLL为32位和64位。问题是，我们的很多C＃项目中的有后构建所需的本地DLL文件复制到该项目的TARGETDIR事件。现在，我们有两个不同版本的本机DLL（32位和64位），我需要能够指定正确的目录，从复制机DLL。我本来以为我可以简单地使用$（平台）的路径，像这样：

 复制$（SolutionDir）\ NativeDll \ $（平台）\ $（配置）$（TARGETDIR）
 

但是，这并不工作，因为$（平台）是的项目的的平台，而不是解决方案级平台。在这种情况下，$（平台）为任何CPU。从我所看到的看着在C＃项目的生成后事件宏，似乎没有成为一个方式来访问正在构建的解决方案级平台。有没有更好的方式来实现我的目标？

我相信该解决方案的平台，不像项目是简单的文本。

我在过去有下降的是：

删除Win32和从溶液中混合平台（和不断增加的项目后这样做）。

将所有的C＃的DLL的搭建值为anycpu的解决方案平台值为anycpu，86，64。 （不要删除值为anycpu，如果你希望能够在Blend中打开，或者如果你在溶液中的任何纯粹的托管应用程序。）

设置C＃的EXE和单元测试建立在86中86解决方案平台和x64的64位解决方案的平台，而不是在值为anycpu解决方案平台打造的。

将所有当地人建立在Win32中，当溶液x86和输出到$（PROJECTDIR）\ BIN \ 86 \ $（配置）和路径，而不是宾中间体同OBJ。 64同样使用x64，而不是86和Win32。

C＃的EXE和单元测试集pre构建的事件他们依靠从相对路径与项目的配置名称复制机DLL

设置单元测试类初始化复制测试bin目录（正确的平台和配置，当然），以测试全部内容出目录。如果使用和#DEBUG不安全的sizeof（IntPtr的）来告诉去哪里寻找测试'bin目录。

手动（使用记事本）增加相对引用路径之外使用的x86 / x64的组件，从解决方案的部署位置解决方案的.csproj文件，所以路径将包括$（平台）和$（配置），并不会为每用户。

微软在Visual Studio中更好的32/64位支持将是非常到位

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?

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

What I have down in the past is:

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

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.)

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.

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.

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)

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.

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.