我有一个纯托管的.NET DLL（程序集），目前正在使用x86的Platform Target进行编译。由于这是纯.NET代码（没有非托管引用或交互操作），它可能/应该是AnyCPU，但无论出于何种原因，它都不是。
这个dll由AnyCPU .NET可执行文件引用。当然，我得到了CSC警告＆＃34; MSB3270：正在构建的项目的处理器架构之间存在不匹配＆＃34;但是可执行文件似乎可以工作，即使在64位Windows上也是如此。但是，我无法确信在64位下运行时不会出现任何问题。
问题：对于纯托管的dll，平台目标（x86 / x64 / AnyCPU）是否重要，因为可执行文件是指示x86 / x64执行的？
或者采用不同的方式：运行64位.NET可执行文件是否会遇到任何加载/运行＆＃34; 32位＆＃34; .NET dll？
答案 0 :(得分：1)
这对.dll很重要，因为你不知道什么样的.exe会想要引用那个dll。
如果您有x86目标，您可能会发现自己处于64位平台上，并为AnyCPU设置了.Net exe。那个exe会启动一个64位进程，你的x86 dll会不喜欢它，或者你最终强迫应用程序以32位模式运行，而它可能在64位模式下做得更好。在另一个方向，如果你决定强制64位，你可能有一个需要设置32位的exe才能支持一个非托管的32位库，现在你仍然没有运气。
对于exe，偶尔有理由强迫应用程序进入一种模式或另一种模式，但是对于你不了解exe的dll，大多数时候AnyCPU是正确的选择。 / p>
当然，如果你做知道exe，你想把它与exe正在做的事情相匹配。
答案 1 :(得分：1)
不打算直接执行的程序集应该是AnyCPU，除非它们引用本机代码或包含unsafe代码块，这些代码块会假设您将运行的处理器。
对于EXE，如果您依赖32位原生DLLS并且没有指定架构，则可能会遇到问题。
答案 2 :(得分：1)
在完成对Joel Coehoorn的回答时，对于某些操作，您也会有不同的行为，例如System.Math.Exp或System.Math.Pow（以及其他许多其他类型的操作），它们不会给你带来相同的结果。
这是由于每个平台上的double类型的精度不同，指令集和寄存器集的大小不同，因此可能会出现舍入错误。但它没有太大的影响，舍入错误出现在15位数之后，但如果你在市场交易应用程序上工作，它会这样做：）
答案 3 :(得分：0)
对于纯托管dll，没有互操作，没有非托管/不安全代码，处理器目录无关紧要。理想情况下，它应设置为AnyCpu。
Machine PE标头仅在启动exe时由OS使用。当点网进程加载dll时，它会忽略该字段。对于一个dotnet dll，此标志仅用于提醒我们测试它的使用范围。
如果使用ngen，那么程序集可能不会在不同位数的过程中使用。