Search

.NET compilers should support a /LargeAddressAware flag by Bill Menees

Active

16
0
Sign in
 to vote
Type: Suggestion
ID: 93771
Opened: 6/1/2006 7:50:45 AM
Access Restriction: Public
0
Workaround(s)
The C# and VB.NET compilers need to support a /LargeAddressAware switch like VC++'s linker does. That will enable a 32-bit EXE to access over 2GB of memory (assuming the /3GB switch is set for the OS).

I've worked around this for now in my build process, but the workaround is tedious:

* Delay-sign my EXE
* Run a post-build step:
    * Call EditBin.exe /LargeAddressAware
    * Run SN -R to fully sign my EXE.

This is doable, but it would be a lot nicer if the compiler (and the VS GUI) provided an option for it.
Details (expand)
Product Language
English
Version
Visual Studio 2005
Category
Base Class Libraries and APIs
Operating System
Windows XP Professional
Operating System Language
US English
Proposed Solution
Add support for a /LargeAddressAware flag in the .NET compilers and in the VS GUI.
Benefits
Improved Performance
Other Benefits
Improved Performance
File Attachments
0 attachments
Sign in to post a comment.
Posted by Fosseus on 11/17/2010 at 12:34 AM
Ed, would you elaborate on what in the Windows ecosystem that is not Largeaddressaware - safe. Is the .NET system itself safe, including things like WCF? I understand that 32-bit ASP.NET runs Largeaddressaware on some 64-bit OSes, so one would think it is, but I appreciate to hear it from you guys.

Regards
Urban Fosseus
Posted by Wayne Hartell on 3/24/2010 at 10:33 PM
Whilst I agree that 64-bit is the ultimate objective here I think Ed you miss the benefit that exes linked with /LARGEADDRESSAWARE gain in terms of virtual address space when running on a 64-bit operating system. We have 32-bit applications that very much benefit from the larger virtual address space when running on 64-bit operating systems. We too are looking to move to 64-bit but as Bill says, it will take time to do this not only with our own code, but also to upgrade 3rd party dependencies to 64-bit. Are you saying that these ecosystem issues also exist under a 64-bit operating system? If so I find it a little hard to see why it's fine to expose the option for C++, but not C#. Having said that, a work around does exist, so it's not going to break us by the sounds.

Regards,
Wayne H.
Posted by Bill Menees on 3/3/2008 at 6:54 AM
That makes sense. I'd like to move to 64-bit too, but I have lots of hosted 32-bit C++ COM objects that will take me several more years to rewrite. In the meantime, my build process workaround is sufficient, and large address mode seems to work for my usage scenarios.

Thanks for your time. Feel free to change the issue status to Closed.
Posted by Microsoft on 2/13/2008 at 1:47 PM
Dear Bill,
We have researched the idea of introducing this option and decided against it. We encourage moving to 64 bit architectures if the 32 bit address space is tight. While setting the large address aware flag in the PE is a valid thing to do, there are several components in the Windows computing ecosystem that were written assuming 2GB of address space that fail in a 3GB configuration. For that reason, we do not want to promote the usage of large address aware.

Regards,

Ed Maurer
Development Lead, C# compiler
Posted by Microsoft on 5/3/2007 at 4:16 PM
Bill -

Thanks for the suggestion. We're going to keep this around for next time, but we won't be able to do this for Orcas. For now, you'll need to use the workaround of running a post-build tool to modify the PE.

Thanks,
Luke Hoban
Visual C# Compiler Program Manager
Sign in to post a workaround.
© 2012 Microsoft Corporation. All rights reserved. Microsoft Connect Terms of Use | Trademarks | Privacy Statement