Visual Studio 中的“首选 32 位”在控制台应用程序 (.NET Core) 下生成 64 位代码答案

【问题标题】：'Prefer 32-bit' in Visual Studio Generates 64-bit Code Under Console App (.NET Core)Visual Studio 中的“首选 32 位”在控制台应用程序 (.NET Core) 下生成 64 位代码
【发布时间】：2020-02-20 16:29:00
【问题描述】：

在 Visual Studio 2019 中创建一个简单的控制台 .NET Core 应用现在将默认使用 AnyCPU 平台（未设置 Prefer 32-bit，如 it was with a .NET Framework app）。

然而，如果打开Prefer 32-bit，结果将不再遵循旧逻辑，即生成一个 x86 可执行文件，而是生成一个 x64。

一些快速检查代码：

Console.WriteLine("Initially allocated: {0} bytes", AppDomain.CurrentDomain.MonitoringTotalAllocatedMemorySize);
int noNumbers = 1000000;
object[] objectArray = new object[noNumbers];
Console.WriteLine("Allocated in the end: {0} bytes", AppDomain.CurrentDomain.MonitoringTotalAllocatedMemorySize);

代码输出旁边的平台设置（红色）显示分配的内存量（橙色）：

object[] 数组中的元素在 x86 平台上占用 4 个字节，在 x64 平台上占用 8 个字节。输出清楚地表明这是 x64 代码。 VMMap 还根据进程中可见的 64 位虚拟地址确认了这一发现（绿色突出显示）：

需要专门选择 x86 作为平台才能获得 32 位可执行文件：

在 Visual Studio 中将 Prefer 32-bit 设置为启用时生成 64 位输出代码是故意更改吗？

在 Windows 10 x64 上的 Visual Studio 2019 16.5 上测试

【问题讨论】：

你看到stackoverflow.com/questions/12066638/…了吗？
（旁白：您可以通过访问Environment.Is64BitProcess更轻松地检查您的进程是否以64位运行）
从您的代码生成的程序集确实打开了该选项。您可以验证但在生成的 dll 上运行 corflags.exe，注意 32BITPREF 标志是如何打开的。但问题是 DLL 不会锁定进程的位数，它是启动 EXE 来完成的。 .NETCore 非常不同，它使用主机。 dotnet.exe 或 VS 项目生成的专用文件。后者遵循平台选择。 Dumpbin.exe /headers 看看吧，机器类型字段。嗯，这有点草率。
@CaiusJard：我知道我不久前就所有事物如何结合在一起进行的一项研究，并在此处发布mihai-albert.com/2019/03/10/net-assembly-cross-bitness-loading，但在 .NET Core 中不再完全适用。
@MatthewWatson：我知道该属性，甚至查看了确切的实现（与其他评论中的链接相同），但我对 .NET Core 不熟悉，因此我没有想被带去兜风 :) 我的理由是 VMMap 不会撒谎。

标签： c# visual-studio .net-core

【解决方案1】：

正如 Hans Passant 的评论所指出的，Visual Studio 将（在其他文件中）构建一个 .exe - 它将完全忽略 Prefer 32-bit 设置，以及一个遵循设置的 .dll（通过切换 32BITPREF） .

我与 Microsoft 支持人员取得了联系，后者又与 Visual Studio 团队的人员进行了交谈。事实证明这是一个已知的事情，GitHub 问题 already exists 用于完全删除 .NET Core 项目的 Prefer 32-bit。事实上，微软支持将其归类为错误。

我还进行了一些测试，就目前而言，对于 .NET Core 控制台应用程序项目，Visual Studio 中的各种平台目标设置将分别确定 .exe 和 .dll 的以下结果：

围绕文件头和生成的进程位数的完整分析是here。

【讨论】：