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

查看:71
本文介绍了Visual Studio中的“首选32位"在控制台应用程序(.NET Core)下生成64位代码的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

现在在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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆