* Fix some post-build signing issues
This fixes some post-build signing issues that are present in the aspnetcore repo
1. Add the .msi extension to be signed by Microsoft400 - Msis must be signed. With in-build signing these get handled explicitly by the wixproj infrastructure. When we do post build signing, we must sign these files.
2. Remove the strong name exclusions. These exclusions are incorrect when applied in post-build and unnecessary for in-build signing. Most importantly, the aspnetcore PKT would not end up re-strong named (it doesn't need to be strong name signed by ESRP since it's strong named in-build) because the PKT doesn't match any of the StrongNameSignInfo specified in arcade. The rest of the entries seem to be mostly about optimization. I could not find any performance difference between these entries being present and not. I am not sure whether they actually even apply to any assets. Moreover, when doing post-build signing, they would conflict with the entries in runtime and other places.
Verification - I have a tool that I wrote which unpacks every file between two directories and compares the strong name, nuget, and authenticode certs between equivalent files. This is the same tool being used to verify post-build signing. This tool shows no difference in any aspnetcore produced asset.
Baseline: https://dev.azure.com/dnceng/internal/_build/results?buildId=836183&view=results
Diff: https://dev.azure.com/dnceng/internal/_build/results?buildId=837176&view=results
* Do not push VS packages for installers when PostBuildSign == true
* Output wix command packages to the installers output path
* Don't import microbuild signing targets from wix when PostBuildSign=true
* Tweaks:
- Don't sign wixpacks when not in post-build signing
- Generate a wixpack for both the original msi name (which the wixproj generates) AND the name we use in the final outputs. This is because while these files are the same, signing differentiates the certificate based on the file name, and wixpack lookup is also based on the file names. Aspnetcore and other repos have uses the final outputs (e.g. dotnet-aspnetcore-runtime-123.5..) as well as the internal names (e.g. AspNetCoreSharedFramework_x64.msi).
- Don't sign msi's when not post-build signing.
* Avoid generating sha512 files for wixpack zips
* Don't run xplat code sign jobs if PostBuildSign == true
* Change original target names
* Conditionalize codesign operations
* Add publishing flag for linux x64 and add deb sha512 generation
* Do not push the x64 linux runtime archive more than once
Changes WiX toolset used to 3.14 to support ARM64
Generates targeting pack from the x86/x64 leg, as it gets produced using a zip that gets generated there.
The ARM64 leg now produces all the necessary msi's, exe, and wixlib needed for the installer to generate a bundle.
* Add light/lit command packages
This adds light command package generation to aspnetcore.
After build of a wix project, generate a light package based off of the inputs that are sent to light.exe/lit.exe.
* Move to latest NuGet.exe
- 5.3.0 -> 5.6.0
- should improve performance and may improve reliability
* Also switch from NuGet.Build.Tasks to NuGet.Packaging
- move to 5.6.0 version here too
- reduce transitive dependencies; we don't need them all
* Always generate checksums as last part of publish job
* Initialize props correctly
* Fix wildcard
* Import Arcade SDK
* Add NoWarn MSB4011
* Make import conditional on GenerateChecksums
* Select specific files to checksum
* Respond to feedback
* AfterTargets -> BeforeTargets
* Update dependencies from Arcade
* Try publishing checksums
* Fix some errors
* Set RelativeBlobPath
* Fix publish location
* Centralize ChecksumExtension
* Fix use of ChecksumExtension in publishing.props
- #13864
- use latest Arcade from '.NET 3 Tools'
- pick up @joeloff's #4083 signing validation fixes
- update signing validation exclusions to get them working
- remove custom embedded package icon bits and use Arcade approach
- also switch VS.Redist.* packages to use license expressions
- `'$(IsTargetingPackBuilding)' == 'false'` should only disable the targeting packs on non-Windows
- disable `CreateTargetingPackNugetPackage` target on Windows
- sfx_x??.cab files are now embedded in aspnetcore-runtime-3.1.0-ci-win-x??.msi files
- no need for same content to appear separately in VS.Redist.Common.AspNetCore.SharedFramework.x??.3.1.3.1.0-ci.nupkg
* Mark all blobs as shipping
- available (though not discoverable) in public dotnetcli feed
* Stabilize package versions
* Remove assumption that Microsoft.AspNetCore.AzureAppServices.SiteExtension packages have same version
- Microsoft.AspNetCore.AzureAppServices.SiteExtension.3.0 ships
- Microsoft.AspNetCore.AzureAppServices.SiteExtension.3.0.x?? do not ship
* Make installer versions consistent
- VS.Redist.Common.AspNetCore.SharedFramework and ...TargetingPack packages are non-shipping
- everything else ships
nit: remove extra whitespace in .nuspec files for the packages
* Correct assumptions in framework unit tests
- tests sometimes do not calculate version properties as product projects do
- Microsoft.AspNetCore.App.Ref and ...Runtime packages may rev versions separately
* Fix last 2 `SharedFxTests` failures
* Correct Microsoft.AspNetCore.App* versions used in ProjectTemplates tests
- `$(SharedFxVersion)` is not useful in test projects due to stable versioning
* Add continue on error for test templates
William Godbe
Matt Mitchell
dotnet-maestro[bot]
Juan Hoyos
Doug Bunting
Kevin Pilch
Chris R
Ryan Nowak
Kevin Pilch
John Luo
Stephen Halter
Jacques Eloff
Maher Jendoubi
DotNet Bot
Justin Kotalik
Jacques Eloff
Justin Kotalik