Forum Discussion

Gregory Goeppel's avatar
Gregory Goeppel
Brass Contributor
Aug 17, 2025

Why is it impossible to sign a .exe that is included in an msix?

I have a solution that has two projects. One projects makes a wpf exe. I call signtool in the post build step and it signs the .exe no problem. The other wapproj project publishes this into an msix and signs the msix bundle no problem. The .exe inside the .msix however is never signed. Why? The msix refuses to use the build output from the dependent project. I get the signing the bundle package prevents alteration on distribution, but this does nothing for protection after installation. No matter what I do I can't sign the contents inside the msix. Is this pointless? Why does Visual Studio only support signing the distribution package and not the contents inside the msix?

4 Replies

  • ayla74108's avatar
    ayla74108
    Copper Contributor

    It sounds like what you’re running into is a common scenario with MSIX packaging. MSIX is designed to guarantee integrity at the package level, not necessarily at the individual file level inside the package. When you sign the MSIX bundle, it effectively ensures that none of the contents (including your .exe) are tampered with after distribution.

    Because of this, Visual Studio and the MSIX tooling generally don’t provide a built-in way to sign individual files inside the package—the signature on the MSIX bundle itself covers all the included files. Trying to sign the internal .exe separately often gets ignored or overwritten during packaging.

    So it’s not really pointless; the package signature is meant to protect the contents after installation. If you need additional file-level signatures, you’d likely have to sign the .exe after installation, which is unusual and not typically necessary for standard MSIX deployment.

    In short: MSIX prioritizes package integrity over individual file signing, which is why Visual Studio behaves this way.

    • Gregory Goeppel's avatar
      Gregory Goeppel
      Brass Contributor

      Now I get why. I have since learned that after deployment the msix installed contents are read only. Since they cannot be altered or infected, there is no need to sign any contents. So just signing the package distribution is all that is necessary. 

  • Have you tried the built-in options from VS (2019 or 2022) to sign the assembly?
    https://learn.microsoft.com/en-us/visualstudio/ide/managing-assembly-and-manifest-signing?view=vs-2022#how-to-sign-an-assembly-in-visual-studio

     

    We sign the files from our packaging tool (Advanced Installer), so I haven't tried lately to sign them directly from VS. However, I see no reason why this shouldn't work.

     

    Disclaimer: I work on the team building Advanced Installer.

    • TIMOTHY_MANGAN's avatar
      TIMOTHY_MANGAN
      MVP

      Yes - it is wise to sign the executables that are inside the MSIX also.  This is needed for more security conscious customers using things like WDAG, AppLocker, and other software execution protection schemes. 

      Bogdan's approach is correct for projects that allow this.  For others that don't (or only allow authenticode signing), you would use a post build script to perform the exe signing.

       

      And then use the build project for MSIX and get the package signed also.

Resources