MSBUILD / csc：处理 x64 mscorlib 警告 1607 的最简洁方法
我正在尝试使用 VS08SP1 的默认项目系统以显式 x64 模式调用 C# 编译（与 AnyCpu 不同）。当我明确地将模块标记为 x64 时，我得到：
警告 CS1607：程序集生成 - 引用的程序集“mscorlib.dll”针对不同的处理器
删除它的一种方法是使用 /nowarn:1607。 根据我的研究，实践中这样做没有问题。如果有人可以强调他们遇到的现实问题，请随时回答。
然而，这只是感觉不对！因此，我使用的另一种方法是执行 /nostdlib+，然后将带有硬编码
<Reference Include="mscorlib">
<HintPath>$(windir)\Microsoft.NET\Framework64\v2.0.50727\mscorlib.dll</HintPath>
</Reference>
这有效并且可能更好（除非有人愿意指出为什么以前的方法更好的原因），但是有人可以确认这是一个适当的事情，希望引用一些权威的东西吗？
I'm trying to use VS08SP1's default project system to invoke a C# compile in explicit x64 mode (as distinct from AnyCpu). When I explicitly mark a module as x64, I get a:
warning CS1607: Assembly generation -- Referenced assembly 'mscorlib.dll' targets a different processor
One way of removing that is with a /nowarn:1607. Based on my research, there are no problems in practice with doing this. If anyone can hilight a real-world issue they've encountered, please feel free to answer.
However, this just feels wrong! So another approach I used was to do /nostdlib+, and then add a <Reference> with a hardcoded <HintPath> to the explicitly 64 bit mscorlib:
<Reference Include="mscorlib">
<HintPath>$(windir)\Microsoft.NET\Framework64\v2.0.50727\mscorlib.dll</HintPath>
</Reference>
This works and is probably better (unless anyone cares to point out reasons why the previous approach is better), but can someone confirm this is an appropriate thing to do, hopefully citing something authorative?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
在这个博客中我发现了一个提案太长，无法将其完全复制到此处，但简而言之，可以通过改编自 此注释：
在项目文件中，您可以在 PropertyGroup 部分为每个构建配置定义一个自定义变量。示例：
只需添加一个标签，例如
，然后使用宏定义引用路径。
您可以将 MyCustomPath 定义到不同的位置以实现不同的构建配置（平台和/或调试/发布）。
如果 MS 在 VS UI 中支持这一点，这个问题就不会存在，但在那之前这将起作用。我使用这种技术在调试和调试中引用相同程序集的不同版本。发布版本。效果很好！
在上面的背诵中，我恢复了源评论中丢失的标签，并将措辞更改为更详细。
来自同一博客的另一篇有趣的文章：
还有一些其他方法可以做到这一点，但它们也需要手动编辑项目文件。一种方法是为 PropertyGroup 部分指定条件。这个 StackOverflow问题突出了条件的使用。
In this blog I found a proposal that is too long to copy it entirely over here, but in short the idea can be described with summary adapted from this comment:
In the project file, you can define a custom variable in the PropertyGroup section for each build configuration. Example:
Just add a tag such as
and then use the macro to define the reference path.
You can define MyCustomPath to a different location for different build configurations (platform and/or debug/release).
The problem would not exist if MS would support this in the VS UI, but until then this will work. I use this technique to reference different versions of the same assemblies in my debug & release builds. Works great!
In the above recitation I recovered the tag that was lost in the source commentarium and changed the wording to be somewhat more detailed.
An additional interesting piece from the same blog:
There’s some other ways to do this but they also require one to manually edit the project files. One way is to specify conditions to PropertyGroup-sections. This StackOverflow question highlights the use of conditions.
我发现通过将项目的目标框架更改为 .NET Framework 4，它消除了警告。
I found by changing my project's Target framework to .NET Framework 4 it eliminated the warning.
我相信您的第二个选项（使用
/nostdlib+ 显式引用）更好，因为如果您要引用不在同一平台上构建的其他程序集，它不会抑制此警告。I believe your second option (explicit reference with
/nostdlib+) is better, because it will not suppress this warning if you were to reference other assemblies not built on the same platform.就我而言，我收到此警告是因为我的解决方案中混合了 x86 和 x64 项目。如果我在所有项目中创建 x86 构建配置，并将其作为构建的目标，则警告就会消失。但是，如果我想全部针对 x64，我相信我必须重建项目（或遵循上面的建议）以针对 x64 框架重新设计它们。
In my case, I had this warning because I had a mix of x86 and x64 projects in my solution. If I create x86 build configurations in all my projects, and target that for the build, the warnings go away. However, if I wanted to target x64 in all, I believe I would have to rebuild the project (or follow advice above) to rework them for x64 framework.