Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make sure the final WiX bundle contains a *signed* MSI #17446

Merged
merged 7 commits into from
Apr 5, 2022

Conversation

DHowett
Copy link
Member

@DHowett DHowett commented Apr 1, 2022

What is this about:

The Release build pipeline was (1) cleaning the PowerToysSetup solution,
which deleted the recently-signed PowerToys MSI and (2) rebuilding the
PowerToys MSI regardless of cleaning (thanks to WiX.)

This resulted in the final bundle still containing an unsigned MSI
despite all our attempts to sign it.

What is included in the PR:

I've turned off build cleaning and broken the dependency between
PowerToysBootstrapper and PowerToysSetup. This results in msbuild not
running the PowerToysSetup project's build steps at all, and therefore
not overwriting the signed msi with a newly-linked unsigned one.

NOTE: This will impact your ability to F5-run the
bootstrapper from within Visual Studio. Going forward, you'll need to
build the MSI separately before building the bootstrapper.

How does someone test / validate:

See screenshots posted in followup comment.

Quality Checklist

  • Linked issue: Installer: internal MSI file is not signed #17410
  • Communication: I've discussed this with core contributors in the issue.
  • Tests: Added/updated and all pass
  • Installer: Added/updated and all pass
  • Localization: All end user facing strings can be localized
  • Docs: Added/ updated
  • Binaries: Any new files are added to WXS / YML

@DHowett
Copy link
Member Author

DHowett commented Apr 1, 2022

image

@DHowett
Copy link
Member Author

DHowett commented Apr 1, 2022

Ah, the CI pipeline does rely on that dependency. We can fix that, but I want to make sure that this is in the right direction.

@Jay-o-Way Jay-o-Way added the Area-Build Issues pertaining to the build system, CI, infrastructure, meta label Apr 2, 2022
@jaimecbernardo jaimecbernardo added the Hot Fix Items we will product an out-of-band release for label Apr 4, 2022
Copy link
Collaborator

@jaimecbernardo jaimecbernardo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need to remove the dependency, though? MSBuild should detect that the file is newer. and that the project doesn't need to be rebuilt.
I think /p:BuildProjectReferences=false would be able to do it as well.
https://docs.microsoft.com/en-us/visualstudio/msbuild/common-msbuild-project-properties?view=vs-2022#list-of-common-properties-and-parameters

@jaimecbernardo
Copy link
Collaborator

And thanks for working on the fix :)

@DHowett
Copy link
Member Author

DHowett commented Apr 4, 2022

Honestly, the most correct way to fix this would be to have the bundle build process pick up a different input directory for the MSI based on whether CIBuild was set to true. I know that. I am just being lazy.

Copy link
Collaborator

@jaimecbernardo jaimecbernardo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We ended up needing to remove the dependency. Let's go with this.
Thank you for the contribution!

@jaimecbernardo jaimecbernardo merged commit 1fc7a59 into main Apr 5, 2022
@crutkas crutkas deleted the dev/duhowett/ffs-msbuild branch April 20, 2022 18:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Build Issues pertaining to the build system, CI, infrastructure, meta Hot Fix Items we will product an out-of-band release for
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants