Visual Studio 中的“首选 32 位"在控制台应用程序 (.NET Core) 下生成 64 位代码 [英] 'Prefer 32-bit' in Visual Studio Generates 64-bit Code Under Console App (.NET Core)

问题描述

在 Visual Studio 2019 中创建一个简单的控制台 .NET Core 应用程序现在将默认为 AnyCPU 平台(没有设置 Prefer 32-bit，如

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

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

在 Visual Studio 中将 Prefer 32-bit 设置为启用时是否会生成 64 位输出代码?

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

解决方案

正如 Hans Passant 的评论所示，Visual Studio 将构建(在其他文件中)一个 .exe - 这将忽略 完全喜欢 32 位 设置，以及一个 .dll 将遵守设置(通过切换 32BITPREF).

我联系了 Microsoft 支持，后者又与 Visual Studio 团队的人员进行了交谈.事实证明这是众所周知的事情，并且 GitHub 问题

围绕文件头和由此产生的进程的位的完整分析是 这里.

Creating a simple Console .NET Core app in Visual Studio 2019 will now default to AnyCPU platform (without Prefer 32-bit set, as it was with a .NET Framework app).

Yet if one toggles on the Prefer 32-bit, the results no longer respect the old logic, whereby an x86 executable would be generated, but instead an x64 is produced.

Some quick code to check:

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);

Platform settings (in red) next to the code's output showing the quantity of memory allocated (in orange):

An element inside the object[] array will take 4 bytes on an x86 platform and 8 bytes on an x64 one. The output clearly shows this is x64 code. VMMap also confirms this find, based on the 64-bit virtual addresses visible within the process (green highlight):

One needs to specifically select x86 as platform to get a 32-bit executable:

Is 64-bit output code being generated when setting Prefer 32-bit to enabled in Visual Studio a deliberate change ?

Tested on Visual Studio 2019 16.5 on Windows 10 x64

解决方案

As Hans Passant's comment indicated, Visual Studio will build (amongst other files) one .exe - which will disregard the Prefer 32-bit setting completely, and one .dll which will obey the setting (by toggling 32BITPREF).

I got in touch with Microsoft Support, whom in turn talked to the folks in the Visual Studio team. It turns out this is a known thing, and a GitHub issue already exists for removing the Prefer 32-bit altogether for .NET Core projects. In fact, Microsoft Support classified it as a bug.

I've also ran a few tests, and as it stands now, for a .NET Core Console App project, the various platform target settings in Visual Studio will determine the following results for the .exe and .dll respectively:

The full analysis around the file headers and the resulting process' bitness is here.

这篇关于Visual Studio 中的“首选 32 位"在控制台应用程序 (.NET Core) 下生成 64 位代码的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！