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

    Question

  • 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?
    Wednesday, September 30, 2009 7:46 AM

Answers

  • 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 by Andreas Hammar Thursday, October 01, 2009 9:04 AM
    Thursday, October 01, 2009 8:17 AM

All replies

  • 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!
    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
    Thursday, October 01, 2009 7:25 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 by Andreas Hammar Thursday, October 01, 2009 9:04 AM
    Thursday, October 01, 2009 8:17 AM
  • Yes!

    Now it's working!

    Thank you so much.

    So, to sum up:

    After editing the LARGEADDRESSAWARE 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
    Thursday, October 01, 2009 9:04 AM