Visual Studio中的“首选32位"在控制台应用程序(.NET Core)下生成64位代码 [英] 'Prefer 32-bit' in Visual Studio Generates 64-bit Code Under Console App (.NET Core)
问题描述
现在在Visual Studio 2019中创建一个简单的Console .NET Core应用将默认为 AnyCPU
平台(不设置 Prefer 32-bit
作为
在 object []
数组中的元素在x86平台上将占4个字节,在x64平台上将占8个字节.输出清楚地表明这是x64代码.VMMap还根据进程中可见的64位虚拟地址(绿色突出显示)来确认此发现:
需要专门选择x86作为平台来获取32位可执行文件:
在Visual Studio中将首选32位
设置为启用时是否正在生成64位输出代码?
在Windows 10 x64的Visual Studio 2019 16.5上测试
正如汉斯·帕桑特(Hans Passant)的评论所述,Visual Studio将(以及其他文件一起)构建一个 .exe
-它将忽略完全希望使用32位
设置,而最好使用一个 .dll
来遵守设置(通过切换 32BITPREF
).
我联系了Microsoft支持部门,后者又与Visual Studio团队的成员进行了交谈.事实证明,这是已知的事情,并且GitHub问题
围绕文件头和所产生的过程的位数的全面分析是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屋!