在x86和x64操作系统上使用相同的.Net解决方案开发-对程序文件DLL的引用

我在一个环境中工作，一些开发人员在x86环境（仍然是WinXP）上工作，其他人在64位环境（WindowsServer2008R2）上工作。该解决方案有很多对程序文件中的DLL的引用。在32位env上这是可以的，但是当移动到64位时，这些引用会失败，因为它们应该指向“c:\Program Files（x86）”-每次签入解决方案并在另一个环境中重新打开时，都需要更新引用。是否有很好的方法来支持这两种环境，或者仅仅是必须为每个体系结构提供具有不同引用的单独解决方案/项目文件

---

更新：抱歉，看来我弄错了。该解决方案最初是在32位上创建的。当我在64位上打开它时，出现了引用命中不同版本dll的问题，所以我更新了引用（在64位上）。当我签入更改并在32位上重新打开时，我发现（x86）文件夹不存在，因此找不到引用。一旦我在32位上更正了引用的位置（和版本），将其签回，获取最新版本并在64位上打开，一切都很好。谢谢你抽出时间

我建议将您的引用从“程序文件”复制到本地“依赖项”文件夹中。您可以从那里添加引用，它将始终使用相对路径。由于这些引用没有安装到GAC中（否则这不会是问题），这将使您不必不断更改设置。

如何通过编译后步骤将x86复制到常规程序文件？我们也遇到了类似的问题，这更多的是考虑大声解决方案

一个解决方案是在32位机器上创建一个NT重分析点，这样“程序文件（x86）”仅指“程序文件”。这就是我们要做的

---

您可以使用SysInternals连接实用程序或mksymlink（如果您有更高版本的操作系统）创建重分析点。

没有意义，Visual Studio是一个32位程序。编译器也是如此。当被要求从c:\program检索文件时，Windows会自动重新映射到（x86）files@Hans：我认为他硬引用了“C:\Program Files”中的程序集，因此.csproj文件中的路径在x64系统上不正确。（虽然，很可能我完全误解了这个问题…@Reed，是的，他是。但只有在64位计算机上关闭文件系统虚拟化时，这项功能才会失效。这需要一个注册表黑客。里德·科普西正在进行他的分析——很抱歉，这个问题没有说得更清楚@RusselMcClure-VB.Net@Hans-我没有修改文件系统虚拟化-但是win2008是一个我没有创建的VM映像，所以我将检查它是如何设置的。该项目最初是在32位中创建的，然后在64位中打开，给出了错误。然后将64位上的引用更改为兼容adn，然后以32位重新打开，再次出现错误。我将在32位中重新设置它们，检查虚拟化，看看发生了什么。