Can I set LARGEADDRESSAWARE from within Visual Studio?

Question

I have a .net assembly that needs to be 32-Bit and needs to be /LARGEADDRESSAWARE.

I know how to do this with EditBin, but I wonder if there is a built-in way in Visual Studio 2010? Or alternatively, did someone write an MSBuild Task for this?

Edit: This is for a C# app, so no linker options sadly :(

Solution 1

You can do it as a Post-build task. In "Build Events" tab, put following command

editbin /largeaddressaware $(TargetPath)

into the "Post-build event command line:"

This is the case for VS2008. I think it should work in the same way for VS2010.

Solution 2

Building on @RouMao's answer, you may get an error message saying that editbin cannot be found. Ensure that the environment in the post-build event command line is setup properly by specifying as follows:

call "$(VS100COMNTOOLS)..\tools\vsvars32.bat"
editbin /largeaddressaware $(TargetPath)

Another thing to understand is that your LARGEADDRESSAWARE enabled application will not run in debugging mode when (under the Debug tab in your project properties) the Enable the Visual Studio hosting process check-box is checked (which it is by default), because the vshost.exe is not properly flagged.

Uncheck that box to debug your application using LARGEADDRESSAWARE.

Solution 3

This is a NuGet package that can set LargeAddressAware on your binary after it's built: https://github.com/KirillOsenkov/LargeAddressAware

It doesn't require editbin.exe as it has a managed app to set the flag programmatically: https://github.com/KirillOsenkov/LargeAddressAware/blob/master/SetLargeAddressAware/LargeAddressAware.cs

Update: To use it, just install the package and add this property in your .csproj:

<PropertyGroup>
  <LargeAddressAware>true</LargeAddressAware>
</PropertyGroup>

Solution 4

If you compile your Assembly with:

<PlatformTarget>AnyCPU</PlatformTarget>
<Prefer32Bit>true</Prefer32Bit> <!--Default !false!-->

than your resulting assembly will automatically receive LARGE ADDRESS AWARE flag.

Tested with VS 2019 (requires Visual Studio 2015+ as per Why does 'Any CPU (prefer 32-bit)' allow me to allocate more memory than x86 under .NET 4.5?).

So you don't need any special actions in most cases. Your AnyCPU assembly will be executed under x86 + LAA by default.

View more solutions

Comments

[WiiMaxx]

for VS 2013 you need to change the first line to call "$(DevEnvDir)..\tools\vsvars32.bat"

[agez]

and for those who are working with VS 2012 the first line is call "$(VS110COMNTOOLS)..\tools\vsvars32.bat"

[Freestyle076]

Don't forget to wrap your $(TargetPath) in quotes "$(TargetPath)"

[Nick]

This works great, but if you use ClickOnce to publish, be aware that it publishes using the files in the obj folder and NOT the ones in bin. To cover both normal build output (used for debugging / running locally) as well as ClickOnce publishes, you need to run editbin against both directories in the Post Build event. I'd also suggest wrapping the TargetPath macro in quotes.

[ToolmakerSteve]

For VS2010, I also use $(DevEnvDir) as mentiond by @WiiMaxx

[Nick Shaw]

Quick update - DevEnvDir no llonger works as of VS2017 due to changes in the paths (see stackoverflow.com/questions/42805662/…). I had to end up using $(VS140COMNTOOLS)

[CyclingFreak]

So largeaddressaware is set automatically once I have added this nuget package? Or do I need to do something in my code?

[Kirill Osenkov]

Add the NuGet package and set <LargeAddressAware>true</LargeAddressAware> to turn it on. Make sure that the .targets file from the NuPkg is included in your build. To do this, build your project using msbuildlog.com and search for "LargeAddressAware" in the structured log.

[jpmc26]

Massively simpler, despite the need to edit the project file manually. At least you don't have to deal with environment variables and trying to install the correct version of the VC++ build tools all that insanity. I do recommend placing the <LargeAddressAware> tag inside the <PropertyGroup>s that are conditional on the x86 platform, though.

[dss539]

Be sure to check out Kirill's answer. His nuget package is very helpful. stackoverflow.com/a/45182578/55721

[rollsch]

Do you need to do this for DLL files in the project as well as the exe, or just the exe is all that is required?

[Kirill Osenkov]

@rolls just the exe

[StayOnTarget]

"Building on @RouMao's answer" ... I guess their name has changed, which answer was it? The accepted one?

[tommyk]

@KirillOsenkov Does it still work with .Net 6 ? In my case it didn't ...

[Kirill Osenkov]

I don’t think it’s needed for .NET 6, as the .exe files generated by it are not managed binaries, but small app host programs that find and start the runtime.