Best Known Method for signing files that get embedded in the (embedded) cab

[wk-bd]

So due to security requirements (authenticity, etc.) we have to sign all the individual files that get sucked into our WiX installer before they get sucked in. Doing this gets tricky if all your files come from the same sln as the WiX project, because typically I'd use ProjectReferences to reference all the files (and make sure that they get built before the WiX project does) and that causes WiX to suck them in as soon as they are all built. And typically signing is a separate step done on the build machine, usually through some locked down script/task that retrieves the signing cert from a locked down cert store.

With that being said, is there a best way to make everything still flow on both the build machine (pausing to sign) and the local dev environment (where signing isn't typically needed)? I've done it a few different ways in the past:

• Don't use ProjectReferences and just assume the files are built (hard-code or harvest them). Use separate solution configurations to build just the binaries, just the installer, and both binaries and installer
• Use ProjectReferences and then build the .wixproj all by itself, using -p:BuildProjectReferences=false so that the signed binaries don't get rebuilt and overwritten

Bonus:
This becomes even messier when using a ProjectReference that has the Publish="true" attribute set (see https://github.com/orgs/wixtoolset/discussions/7403), since for some reason WiX thinks that it needs to build/find the publish output under its own obj folder (as opposed to the other project's normal publish location). The only way I could think to make this work with signing was to remove the Publish="true" attribute, add the Publish target to the other project's default targets, and then use a relative path from the project's TargetPath variable. If anyone can think of a better way (or better yet, design/implement a feature that makes this easier), I'm all ears!

[wmanning]

Not sure if I followed everything but I had issue where files would be copied too before they could be signed.
I have same requirement to sign some exe and dll outputs.

Not sure if this would work for you. Just thought I'd share.

I use injection to create a step after TargetsTriggeredByCompilation that does the signing. From what I remember after compile the files are still in the obj folder, then below is called to sign them, and then they are copied to the bin folder and so on.

I have the .proj that I inject (say called extend-signExeDll.proj) some of which consists of:

<PropertyGroup>
    <TargetsTriggeredByCompilation>
      $(TargetsTriggeredByCompilation);
      CustomAfterCompile
    </TargetsTriggeredByCompilation>
  </PropertyGroup>

Where CustomAfterCompile is the Target that signs the desired file.

In my main solution.proj I have something like:

<PropertyGroup>
    <FileToInject Condition=" '$(FileToInject)'=='' ">$(MSBuildThisFileDirectory)extend-signExeDll.proj</FileToInject>
</PropertyGroup>

<ItemGroup>
    <Projects3 Include="$(SourcePath)\somepath\someExe.csproj">
      <AdditionalProperties>
        Configuration=Release;
        PlatformTarget=AnyCPU;
        CustomAfterMicrosoftCommonTargets=$(FileToInject);
      </AdditionalProperties>
    </Projects3>
  </ItemGroup>

... a target that calls MSBuild on item group Projects3 above...

Took a quick look on and I believe this is same if you want another source: https://stackoverflow.com/questions/11667510/determine-if-msbuild-corecompile-will-run-and-call-custom-target

[wk-bd]

Thanks for sharing. Unfortunately this will not work for my situation because our injection point is currently designed for the pipeline level. But good thoughts!

[chrpai]

This is one of the many reasons that I put my app code in one solution and my installer code in another and don't use project references across them. It's just easier to manage a variety of scenarios when they are more loosely coupled. My build automation goes something like:

Build Application \application publishes to \installer\deploy
Sign Application ( files in \installer\deploy ) in one batch
Build Installer - various msbuild steps make sure the msi, bundle,bal,exe and so on are all signed.

I use Azure Trusted Signing because you can't beat $10/mo. But if your doing things like LUA Patching it won't work for you because the cert details are always rolling and your whitelist in the MsiPatchCertificate table will always be out of date.

[wk-bd]

Yes, that makes sense. I just wish that I could reap the benefits of both loose and tight coupling at the same time 😄 Guess I can't have my cake and eat it too!

[chrpai]

Yes, that makes sense. I just wish that I could reap the benefits of both loose and tight coupling at the same time 😄 Guess I can't have my cake and eat it too!

I have an FOSS tool called IsWiX has project templates (scaffolding) and graphical designers that accelerates installer development. When I designed the graphical designers I decided to go with loose coupling as it was easier to code and draws a clear line in the sand between app code and installer code. You might want to checkout IsWiX Tutorials so get an overview of how it works. There are examples for a desktop app, windows service and IIS hosted webapp.

[chrpai]

I'm not really saying this would be ideal but you could as a postbuild step extract the cab and decompress it, sign the files then recreate the cab and put it back into the MSI. This is possible with custom build automation that uses the DTF windows installer library. Finally sign the MSI. It does add complexity and build time though.

[wk-bd]

Haha I never would've thought of that 😄