Roslyn: [Proposal] Add an `LARGE_ADDRESS_AWARE` switch to the .NET compiler

[Unknown6656]

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?_

[sharwell]

This is already implemented:

https://github.com/dotnet/roslyn/blob/0846ba67968d5bec15f5119b99849497ff987f49/src/Compilers/Core/Portable/Compilation/Compilation.cs#L1644-L1646

• Use X86 platform to get a binary that runs as a 32-bit image and is not large address aware
• Use Any CPU+Prefer32Bit to get a binary that runs as a 32-bit image and is large address aware

[AArnott]

Thanks, @sharwell. That's a very simple workaround.

How does it work when you're compiling for .NET Native though, where one must choose a CPU architecture rather than "any cpu"?

[tannergooding]

I agree, there should be a way to explicitly set these PE header flags as part of the compilation.

[sharwell]

@AArnott I've never used .NET Native. Sounds like a bug should be filed there to work with Any CPU outputs.

[tannergooding]

@sharwell, it also seems like a bug that you cannot set LAA for explicit x86, but it magically gets set for AnyCPU/Prefer32Bit.

There are native libraries you could potentially be interoping with that are not LAA, and will fail with that assumption.

There are also cases where you are explicitly targeting x86 because AnyCPU is invalid (explicit x86 prevents the binary from being loaded in a 64-bit processes, AnyCPU+Prefer32Bit does not) but where you may still want LAA.

[AArnott]

I'm not sure if .NET Native has a bug or not. I was just wondering about that scenario.

+1 to @tannergooding's points. We compile with x86 sometimes because we know we'll be loading x86 native binaries, so x64 is not an option. The compiler/build knows this and will actually emit warnings if we reference x86 assemblies while targeting AnyCPU ourselves. So yes, there should be a way to require x86 and still be LAA.

[monty241]

From the header I understand that this also might affect dll libraries. We create various vsto applications which should ship as anycpu if possible since some users have excel, word or outlook 32-bit and some 64-bit.

Is there a good way to have these libraries also run in Excel versions with LAA and use the memory advantage, without loosing the option to use them with 64-bit office?