Update SWIX generation#10582
Conversation
Co-authored-by: Daniel Plaisted <[email protected]>
| if (!string.IsNullOrEmpty(MachineArch)) | ||
| { | ||
| msiWriter.WriteLine($" vs.package.machineArch={MachineArch}"); | ||
| } |
There was a problem hiding this comment.
If these are mutually exclusive, would it make sense to error out if the wrong combinations are set?
There was a problem hiding this comment.
Visual Studio does allow you to set all three, though there are some combinations that would never make sense. I'll have a chat with VS to confirm if they are validating anything, but I think it would be good to guard against invalid combinations on our side. We have implemented other checks to catch issues early, otherwise we only see it when the packages flow to VS and at that point, a fix requires rebuilding the whole stack from the runtime. Thanks for the suggestion.
There was a problem hiding this comment.
I checked with VS, there are no explicit validations. They simply trim out invalid items that cannot be installed.
|
Any more concerns on the PR? @mmitche can you please help merge this once folks have signed off. I'm in the process of prepping the dotnet/runtime PRsand we can port this to 7.0 ASAP to unblock the next round of insertions and servicing. |
|
@mmitche can you maybe go ahead and merge this. We have tests covering the changes and I've tested it with 6.0 builds of runtime as well. We need to get the code flows into runtime to unblock things for the next servicing release. |
4 participants
Various fixes for SWIX projects for workloads.
machineArchproperty and support for arm64. Manifests that do not support arm64 will no longer generate SWIX packages for the arm64 MSI. Previously we always setchipto the MSI platform, generating invalid SWIX:vs.package.chip=arm64productArchproperty for SWIX projects. It's unnecessary for workloads and increases the relative path for the package cache.