index > ClickOnce and Setup & Deployment Projects > How to set LARGEADRESSAWARE for a ClickOnce app? Signing breaks with flag

How to set LARGEADRESSAWARE for a ClickOnce app? Signing breaks with flag

Hi,

I've been wrestling with this for a while now. I have an app that uses a lot of mem and really would benefit from being LargeAddressAware.

Problem in short: With the LAA-flag, the app won't start.

Empirical results:

1) I have a release script that runs the entire ClickOnce publishing, then re-signs the executables and dlls, then re-creates the manifest, signs it etc

2) Running the script gives me an app that installs and works nicely

3) Adding this to the post-build breaks the app:

editbin /LARGEADDRESSAWARE <path>/obj/Publish/app.exe

(yes, I know, we have a build config that's called Publish - idiotic - but works...)

The error message I get is:

Activation of \betabox\appbeta\app.application resulted in exception. Following failure messages were detected:

+ Strong name signature not valid for this assembly app.exe.

Both my the manifest and the exe is signed by a valid code signing cert. And the script works fine when the flag does not get set.

I've tried without my script as well, with just the editbin command in the post-build and publishing through VS - same error.

So - is it totally impossible to publish an app with LARGEADRESSAWARE set through ClickOnce?

Andreas Hammar Wednesday, September 30, 2009 7:46 AM

Hi Andreas,

Never mind.

>Will it make a difference if I use SN.exe instead of SIGNTOOL.exe?

They are two different tools. Sn.exe is a strong name tool.
Sign Tool is a command-line tool that digitally signs files, verifies signatures in files, or time stamps files.

Strong Name tool (sn.exe) helps sign assemblies with strong names. Sn.exe provides options for key management, signature generation, and signature verification.
http://msdn.microsoft.com/en-us/library/k5b5tt23%28VS.80%29.aspx

The way I think of sn.exe is because of the error message. Do you really use strong name for your application assembly? If you don’t know how to check that, please follow this way.
1. Right click your EXE project and choose Properties.
2. Select Signing page on that window. Do you see the checkbox “Sign the assembly�?being checked? If it is checked, your assembly are strong named.

I think when you add LARGEADDRESSAWARE flag; the strong name has been destroyed. That result in the error message.

Addition, could you please tell me why your application need such large memory? The best solution for this issue would be turn to x64 operating system.

Hope my support gives you some light.

Sincerely,
Kira Qian
Send us any feedback you have about the help from MSFT at fbmsdn@microsoft.com

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework!

Marked As Answer byAndreas Hammar Thursday, October 01, 2009 9:04 AM

Kira Qian Thursday, October 01, 2009 8:17 AM

Hi Andreas,

> Strong name signature not valid for this assembly app.exe

From the error message you provided me, it seemed the strong name has been destroyed after you use editbin to add “LARGEADDRESSAWARE�?to the PE file. Did you use strong name for your application? So I think you can sign the assembly after you add LARGEADDRESSAWARE flag.

Here are the steps:
1. Build your project with delay sign option for EXE file and copy all assembly to a folder (named OutputFolder).
2. Add LARGEADDRESSAWARE flag to the PE file with editbin.
3. Use sn.exe to resign the PE file.
4. Deploy the application files in the OutputFolder manually with mage.exe (I think this step is done by your release script).

After I did all these steps, I used dumpbin to view the PE file header, the “Application can handle larger (>2GB) address�?flag is still there. However, the recommend way to do this is turn to x64, that is a considered solution in the long run.

More information about this kind of issue
http://social.msdn.microsoft.com/Forums/en-US/clr/thread/c50ea343-b41b-467d-a457-c5a735e4dfff/
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=93771&wa=wsignin1.0

Please try the steps and tell me if it works on your side. If you have any question, please feel free to tell me.

Sincerely,
Kira Qian
Send us any feedback you have about the help from MSFT at fbmsdn@microsoft.com

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework!

Kira Qian Thursday, October 01, 2009 6:51 AM

Hi Kira,

Thank you very much for your reply, the first link I hadn't seen - realized that I have mostly been searching for LAA and "ClickOnce" - which that post did not have in it, sorry for that.

Anyway, I will try your suggestion, but what I'm doing at the moment is almost the same. The steps my script performs are:

(I've left out some folder hopping)

## script start ##

:: In post-build - set the flag

editbin /LARGEADDRESSAWARE <path>/obj/Publish/app.exe

:: After the build has completed

:: Remove .deploy from all files

:: for each file recursively do, if extension is deploy, rename to drive\path\name

for /R %%f in (*) do if %%~xf==.deploy move "%%~f" "%%~df%%~pf%%~nf"

:: Re-sign all dlls and exe with real certificate

for /R %BIN_DIR% %%f in (*.dll) do signtool sign /a /i "Thawte" /t http://timestamp.verisign.com/scripts/timstamp.dll "%%f"

for /R %BIN_DIR% %%f in (*.exe) do signtool sign /a /i "Thawte" /t http://timestamp.verisign.com/scripts/timstamp.dll "%%f"

:: UPDATE APPLICATION MANIFEST

mage -Update "app.exe.manifest"

:: rename files to .deploy

for /R %%f in (*) do if not %%~xf==.manifest move "%%~f" "%%f.deploy"

:: SIGN APP MANI

mage -Sign "app.Exe.manifest" -CertHash XXXXXXXXXXXXXXXXXXX -TimeStampUri http://timestamp.verisign.com/scripts/timstamp.dll

:: CREATE DEPLOY MANI

mage -Update app.application -AppManifest "app.Exe.manifest" -providerUrl %PROVIDER_URL%/app.application

:: SIGN DEPLOY MANI

mage -Sign app.application -CertHash XXXXXXXXXXXXXXXXXXX -TimeStampUri http://timestamp.verisign.com/scripts/timstamp.dll

:: SIGN BOOTSTRAPPER

signtool sign /a /i "Thawte" /t http://timestamp.verisign.com/scripts/timstamp.dll "%PUBLISH_SOURCEDIR%\%BOOTSTRAPPER_FILE_NAME%"

And finally an XCOPY deployment of all files to the production server.

## script end ##

The final touché: I'm normally running this script with additional obfuscation steps - and the script handles the obfuscated dlls nicely by the re-signing and re-generation of manifests. That is why I'm puzzled that it's not working for the LAA flag.

Will it make a difference if I use SN.exe instead of SIGNTOOL.exe?

Thank you again.

Sincerely

Andreas

Andreas Hammar Thursday, October 01, 2009 7:25 AM

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework!

Marked As Answer byAndreas Hammar Thursday, October 01, 2009 9:04 AM

Kira Qian Thursday, October 01, 2009 8:17 AM

Yes!

Now it's working!

Thank you so much.

So, to sum up:

After editing theLARGEADDRESSAWARE flag in post-build, I also had to do:

cd$(ProjectDir)
sn -Ra obj\$(ConfigurationName)\app.exe PublicPrivateKeyFile.snk

That re-creates the STRONG NAME for the exe.

All my other signing with signtool is just packaging of the files and manifests.

Thank you so much Kira - hope this can help someone else out there as well!

/Andreas

Andreas Hammar Thursday, October 01, 2009 9:04 AM

You can use google to search for other answers

Custom Search

More Threads

• Wix: User only settings and Windows Installer Repair

• Clickonce not autoupdating

• app from website - not trusted?

• How to add the application short cut or foder to All Programs menu

• Click-Once deployed app - need to change .config.deploy file

• Deploying a C#.NET WinForm Application with SQLSERVER 2005 Express Edition

• How to hide the config file after Setup

• Prerequisite could not be found for bootstrapping

• Setup and Deployment project

• Publish a VB 2005 Program