我有一个纯托管的 .NET dll（一个程序集），目前正在使用 x86 平台目标进行编译。由于这是纯 .NET 代码（没有非托管引用或互操作），它可以/应该是 AnyCPU，但无论出于何种原因，它都不是。
AnyCPU .NET 可执行文件正在引用此 dll。当然，我收到 CSC 警告“MSB3270：正在构建的项目的处理器架构不匹配”，但可执行文件似乎可以工作，即使在 64 位 Windows 上也是如此。但是，我无法确定在 64 位下运行时不会出现任何问题。
问题：纯托管 dll 的平台目标 (x86/x64/AnyCPU) 是否重要，因为可执行文件是指定 x86/x64 执行的那个？
或者换一种说法：正在运行的 64 位 .NET 可执行文件是否会在加载/运行“32 位”.NET dll 时遇到任何问题？
【问题讨论】：
标签： .net .net-assembly
对于 .dll 可能很重要，因为您不知道哪种 .exe 会想要引用该 dll。
如果您有 x86 目标，您可能会发现自己处于 64 位平台上，并为 AnyCPU 设置了 .Net exe。该 exe 将启动一个 64 位进程，并且您的 x86 dll 不喜欢它，或者您最终强制应用程序在 32 位模式下运行，而它在 64 位模式下可能做得更好。在另一个方向，如果你决定强制 64 位，你可能有一个需要设置 32 位的 exe 以支持非托管的 32 位库，现在你仍然不走运。
对于 exe，有时会强制应用程序进入一种模式或另一种模式，但对于您不知道 exe 的 dll，大多数情况下 AnyCPU 是正确的选择。
当然，如果您确实知道该 exe，则希望将其与该 exe 正在执行的操作相匹配。
【讨论】：
不打算直接执行的程序集应该是 AnyCPU，除非它们引用本机代码或包含unsafe 代码块，这些代码块对您将在其上运行的处理器做出假设。
对于 EXE，如果您依赖 32 位本机 DLLS 并且未指定架构，则可能会遇到问题。
【讨论】：
在完成 Joel Coehoorn 的回答后，您还将对某些操作有不同的行为，例如 System.Math.Exp 或 System.Math.Pow（以及许多其他双类型操作），它们不会给您相同的结果.
这是由于这些平台上的双精度类型不同，指令集和寄存器集的大小不一样，因此可能会出现舍入错误。虽然它没有太大影响，15 位数字后会出现舍入错误，但如果您使用市场交易应用程序，它会：)
【讨论】：
dll会导致差异。区别应该来自exe 的proc arch，而不是dll。如果有人可以请验证。
对于纯托管 dll、无互操作、无非托管/不安全代码，处理器架构无关紧要。理想情况下，它应该设置为 AnyCpu。
Machine PE 标头仅由操作系统在启动 exe 时使用。当 dot net 进程加载 dll 时，它会忽略该字段。对于 dotnet dll，此标志仅用于提醒它经过测试可以使用多远。
如果使用ngen，则程序集可能不能用于不同位数的进程。
【讨论】：