MSBUILD / csc：处理 x64 mscorlib 警告 1607 的最简洁方式

Posted 2023-02-16

【中文标题】MSBUILD / csc：处理 x64 mscorlib 警告 1607 的最简洁方式

【英文标题】：MSBUILD / csc: Cleanest way of handling x64 mscorlib warning 1607

【发布时间】：2009-08-13 15:31:42

【问题描述】：

我正在尝试使用 VS08SP1 的默认项目系统以显式 x64 模式调用 C# 编译（与 AnyCpu 不同）。当我将一个模块显式标记为 x64 时，我得到一个：

警告 CS1607：程序集生成 -- 引用的程序集“mscorlib.dll”针对不同的处理器

删除它的一种方法是使用/nowarn:1607。 Based on my research，在实践中这样做没有问题。如果有人能指出他们遇到的现实问题，请随时回答。

但是，这感觉不对！所以我使用的另一种方法是做/nostdlib+，然后将带有硬编码<HintPath> 的<Reference> 添加到显式64 位mscorlib：

<Reference Include="mscorlib">
  <HintPath>$(windir)\Microsoft.NET\Framework64\v2.0.50727\mscorlib.dll</HintPath>
</Reference>

这可行并且可能更好（除非有人关心指出以前的方法更好的原因），但是有人可以确认这是一个合适的做法，希望引用权威的东西吗？

【问题讨论】：

我遇到了同样的问题。会对解决方案感兴趣。谢谢。

【参考方案1】：

In this blog我发现一个提案太长了，这里无法完全复制，但总之这个想法可以用this comment改编的摘要来描述：

在项目文件中，您可以在 PropertyGroup 部分为每个构建配置定义一个自定义变量。示例：

<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|x64'">
    <MyCustomPath>C:\Windows\Microsoft.NET\Framework64</MyCustomPath>
</PropertyGroup>

只要加一个标签比如

<Reference Include="System.Data">
    <HintPath>$(MyCustomPath)</HintPath> 
</Reference>

然后使用宏定义参考路径。 您可以为不同的构建配置（平台和/或调试/发布）定义 MyCustomPath 到不同的位置。 如果 MS 在 VS UI 中支持这一点，问题就不会存在，但在那之前这将起作用。我使用这种技术在我的调试和发布版本中引用相同程序集的不同版本。效果很好！

在上面的背诵中，我恢复了在源评论中丢失的标签，并将措辞改得更详细一些。

来自same blog 的另一篇有趣的文章：

还有其他一些方法可以做到这一点，但它们也需要手动编辑项目文件。一种方法是为 PropertyGroup-sections 指定条件。这个*** 问题突出了条件的使用。

【讨论】：

+1 在我的场景中，我实际上并不需要这种技术——我一直想要x64。仍然没有接受这个问题 - 我想知道微软会推荐什么来处理内置错误（不必容忍他们可怕的论坛软件：P）

【参考方案2】：

我发现通过将项目的 Target 框架更改为 .NET Framework 4，它消除了警告。

【讨论】：

+1 但是转移到不同的 CLR 和 VS 是作弊：P（Serioulsy，感谢您抽出宝贵时间回答）

终于接受 - 虽然这并不能回答实际问题，但这是我最终使用的解决方案，我想这几乎是这个生态系统中惯用的“答案”......

这无论如何都不是问题的解决方案。它可能对您 Todd 有用，但许多项目不能简单地更改为针对不同的框架。

对我不起作用。我的目标是 .NET 框架 V4.0，但仍然收到警告。

这种方法的另一个问题是 .NET 4 并不总是一个解决方案。我们正在构建一个可能部署在多个客户环境中的项目，我们无法控制他们是否有 4 个。我们的经验是，4 有时也会导致其他企业软件出现问题，因此这些客户可能不会选择它。

【参考方案3】：

我相信您的第二个选项（使用 /nostdlib+ 显式引用）更好，因为如果您要引用不是在同一平台上构建的其他程序集，它不会抑制此警告。

【讨论】：

+1 有见地（初读我不确定）。我将推迟接受坚持我的挑剔评级：P（说真的：我有兴趣听到我的第二种方法的任何负面影响 - 如果没有缺点，你会认为它会被 VS 违约）。不过我猜从msbuild 的角度来看，这很有意义，csc 不应该将所有这些策略直接内置到工具中

我想不出任何缺点，除非您在 x86 机器上编译，该机器可能没有该路径上的程序集。

就 msbuild 而言（真正的团队构建），我的偏好是在该平台上运行每个平台构建。

【参考方案4】：

就我而言，我收到此警告是因为我的解决方案中混合了 x86 和 x64 项目。如果我在所有项目中创建 x86 构建配置，并将其作为构建目标，警告就会消失。但是，如果我想完全针对 x64，我相信我必须重新构建项目（或按照上面的建议）以针对 x64 框架重新设计它们。