Conversation
joeloff
commented
May 10, 2021
- Add support for locating workload manifests in data folder
- Generate MSI JSON manifests for payload packages
- Generate MSI payload projects
- Add installation record registry keys to workload pack MSIs
|
@marcpopMSFT @lewing @pranavkm next round of updates for build tasks, most impact CLI installs which we won't need until preview6 |
|
@chcosta if you get a chance to look at this I'd appreciate it. This is for Preview5 |
chcosta
left a comment
There was a problem hiding this comment.
I don't have much interesting feedback. looks fine to me.
| if (string.IsNullOrWhiteSpace(nupkg.Title)) | ||
| { | ||
| Log?.LogWarning($"'{sourcePackage}' should have a non-empty title. The MSI ProductName will be set to the package ID instead."); | ||
| Log?.LogMessage(MessageImportance.High, $"'{sourcePackage}' should have a non-empty title. The MSI ProductName will be set to the package ID instead."); |
There was a problem hiding this comment.
Seems like this should be either a warning, or a normal importance message, but high importance seems weird to me. Also, this is just a nit and it's fine (to me) to leave this as-is.
There was a problem hiding this comment.
Yeah, it's not a problem if these items are missing because of how folks are building workloads. When it's a warning though, the builds in the installer repo will fail, and any changes to the packages requires respinning the full net stack since the workload packages for WASM originate in the dotnet/runtime repo