Proposal: Add an LARGE_ADDRESS_AWARE switch to the .NET compiler

[Unknown6656]

This is a copy/pasta from dotnet/roslyn#9209

---

I sometimes write applications and/or libraries which need the LARGE_ADDRESS_AWARE-flag set. I usually solve this by calling editbin.exe as postbuild-event.

Would it be an good idea to add a corresponding switch directly to the C#/F#/.... compiler?
It would have the following pros:

• one could save a few miliseconds/seconds of compilation time and postbuild-event calls
• it is easier to use for regular users (when properly integrated into VisualStudio)
• would not influence the compiler speed a lot - as it is only one argument which must be parsed and one bit which must be written
• reduce the amount of possible error sources during execution and project build (e.g. when some uses editbin incorrectly)

Or am I the sole one appending the editbin-postbuild to every second project of mine?

---

An alternative could be the introduction of an pseudo-attribute like

[assembly: LargeAddressAwareApplication]

[iam3yal]

@Unknown6656 I think it's more of a tooling issue than a language issue. :)

[sharwell]

@Unknown6656 The C# compiler already does this.

Architecture	LAA	Settings
X86	No	Platform: X86
X86	Yes	Platform: Any CPU, Prefer32Bit: True
X64 when available	N/A	Platform: Any CPU, Prefer32Bit: False
X64 only	N/A	Platform: X64

[sharwell]

@Unknown6656 I updated the linked Roslyn issue to show the code which implements the feature.

[Unknown6656]

@eyalsk : I know, I just wanted to raise more people to the issue and I thought the roslyn-repo was more busy with bug fixes and people here have more 'free time' for language or compiler features.

@sharwell : Thank you very much for your help and information! I was not aware of the implementation.

[iam3yal]

@Unknown6656 Ahh okay, fair enough. :)

[gafter]

Closing, as there is no language change proposed herein.

[AraHaan]

Actually LAA is possible on 64 bit processes themselves too, or so I see the option on CFF Explorer on 64 bit applications / dlls that I load into it.

Infact I plan to see if I can find the code in the compiler to move what it does to set LAA on prefer 32 bit on AnyCPU programs to a flag so the developer actually opts into it themselves instead of setting it and forcing them to prefer 32 bit even if they know the application MUST always be 32 bit (in the case of them using reflection to load an 32 bit c++/clr dll that does stuff that is impossible to do in C#/VB.NET)

There is another side of the story too, what if on 64 bit devices they want to use reflection to load an 32 bit c++/clr dll, or if it fails (since reflection is used to load it it will fail as it will be a 64 bit process) to load the 64 bit version of that c++/clr dll using the Assembly Resolve on the application's app domain. They might still need to set LAA because of the fact if they use Any CPU, if it's not set and the program is running on a 32 bit OS that program would then blow up on them even though it is stable and does perfectly valid stuff (just that it would lack LAA being set).

I would need help in pointing where at in the code that I can add and move it all to a compiler flag that would set it in not only 32 but also 64 bit compilations in both of the C# and VB.NET Compilers mainly because manually setting it invalidates signatures created when setting the compiler to sign the assembly using an Code Signing Certificate (*.cer) file to validate where the assembly comes from (Microsoft does this with their dlls to code sign to validate if they are official builds or not). And no this is not like strong naming the assembly.

Letting the developer opt into it is better than doing like it is now, while it is not a language feature, I will need to see if I can fix the compilers as this is unacceptable.