如何从 C# 项目的生成事件访问 Visual Studio 解决方案级别平台？
我们有一个大型 VS 2010 解决方案，主要是 C# 代码，但也有一些各种 C# 项目依赖的本机 DLL（包括我们的单元测试 DLL）。我们正在尝试支持 32 位和 64 位版本的库。因此，我们现在将本机 DLL 构建为 32 位和 64 位。问题是我们的许多 C# 项目都有构建后事件，这些事件会将所需的本机 DLL 复制到项目的 TargetDir 中。现在我们有两个不同版本的本机 DLL（32 位和 64 位），我需要能够指定正确的目录来从中复制本机 DLL。我原本以为我可以简单地在路径中使用 $(Platform) ，如下所示：
copy $(SolutionDir)\NativeDll\$(Platform)\$(Configuration) $(TargetDir)
但这不起作用，因为 $(Platform) 是项目的平台，而不是解决方案级别平台。在本例中，$(Platform) 是“任何 CPU”。从我所看到的 C# 项目中的构建后事件宏来看，似乎没有办法访问正在构建的解决方案级别平台。有更好的方法来实现我的目标吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我相信解决方案的平台与项目的平台不同，只是文本。
我过去所做的是：
从解决方案中删除 Win32 和“混合平台”（并在添加项目后继续这样做）。
将所有 C# DLL 设置为在解决方案平台 AnyCPU、x86、x64 中构建为 AnyCPU。
（如果您希望能够在 Blend 中打开或者解决方案中有任何纯托管应用程序，请不要删除 AnyCPU。）
将 C# EXE 和单元测试设置为在 x86 解决方案平台中构建于 x86 以及在 x64 解决方案中构建于 x64平台，而不是在 AnyCPU 解决方案平台上构建。
当解决方案为 x86 时，将所有本机设置为在 Win32 中构建，并输出到 $(ProjectDir)\bin\x86$(Configuration) 并中间与路径中的 obj 而不是 bin 相同。 x64 与 x64 相同，而不是 x86 和 Win32。
设置 C# EXE 和单元测试的预构建事件，以从项目配置名称为 $(Config) 的相对路径复制它们所依赖的本机 DLL
设置单元测试的类初始化以复制测试 bin 目录的全部内容（正确的平台）当然还有配置）到测试目录。使用 if #DEBUG 和 unsafe sizeof(IntPtr) 来告诉在哪里查找测试的 bin 目录。
手动（使用记事本）添加到解决方案外部使用解决方案部署位置中的 x86/x64 程序集的 .csproj 文件的相对引用路径，因此路径将包括 $(Platform) 和 $(Configuration)，并且不会针对每个用户。< /p>
Microsoft：Visual Studio 中更好的 32/64 位支持将真正到位。
I believe the solution's platform, unlike that of the projects is simply text.
What I have done 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.
当我必须这样做时，我只是将所有程序集都可构建为 x86 或 x64 而不是 AnyCPU，并且有两个单独的输出包。如果您知道自己的进程必须是 32 位或 64 位，那么 AnyCPU 确实没有任何意义。
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.
我自己没用过，但是Build ->批量构建可能就是您想要的。有了它，您可以构建多个平台。
http://msdn.microsoft.com/en-us/library/169az28z.aspx
当然，这实际上并不能让您访问解决方案的“平台”，但您不需要这样做，因为您将单独构建每个平台。
更新：
如果您想自动构建，请创建一个包含以下内容的批处理文件
，其中“平台”是“Release|Any CPU”、“Release|x86”等，并对需要构建的每个配置重复该行。使用配置管理器为 x86 和 x64 构建每个项目，您应该拥有您想要的。
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
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.
我认为“活动解决方案配置”没有等效的宏属性。
我的建议是在所有 .csproj 文件中手动添加自定义属性，如下所示（请参阅为每个配置/平台组合添加的新
MyVar自定义属性）：您可以使用“卸载项目”并“编辑 MyProject.csproj”菜单可在 Visual Studio 中编辑 .csprojet。重要的是要知道，即使您使用普通 GUI 编辑器保存这些“未知”值，Visual Studio 也不会破坏它们。
然后在构建后事件中，您可以使用这些值，例如：
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
MyVarcustom property added for each configuration/platform combination):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:
Francesco Pretto 有一个扩展可以帮助解决这个问题。它似乎有一些怪癖和缺陷，但它是一个开始。
http://visualstudiogallery.msdn.microsoft.com/619d92a2-4ead-410d-a105-135f7b4b4df9
github上的源代码：
https://github.com/ceztko/SolutionConfigurationName
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