[release/3.1] Give .msi's non-stable branding

[wtgodbe]

Customers have reported issues with our .MSI's when repairing VS. We believe the issue is due to the ProductCode/ProductVersion of the installers not being unique per build, but instead being unique per package version. Giving the MSI's suffixed versions should fix the issue

CC @Pilchie @joeloff

[joeloff]

The inputs for the ProductCode haven't changed I think. The version constructed for the MSI itself is coming from

aspnetcore/src/Installers/Windows/Wix.targets

Line 5 in b3c6c43

<Version>$(AspNetCoreMajorVersion).$(AspNetCoreMinorVersion).$(AspNetCorePatchVersion).0</Version>

And then combined with a product identifier to eventually generate the GUID:

aspnetcore/src/Installers/Windows/Wix.targets

Line 30 in b3c6c43

<GenerateGuid NamespaceGuid="$(NamespaceGuid)" Values="$(ProductNameShort);$(GuidInputs)">

[wtgodbe]

@joeloff thanks for pointing that out, I pushed eeba5fd to append the build number. $(_BuildNumberLabels) is something like .20263.6

[Pilchie]

It sounds like we also need this for 2.1? Is that right @joeloff ?

[joeloff]

@Pilchie Yes, the issue has come up for 2.1 as well.

[joeloff]

@wtgodbe is BuildNumberLabels a 2 part version? If so, this will turn Version into a 5 part number. That's fine for generating the GUID, however, the version property will be validated when the MSI is compiled and WiX may reject it I think.

[wtgodbe]

Yes, it is. I could replace it with FileRevisionVersion which is just the 20263 part. In that case though it wouldn't match the PackageVersion, is that alright? PackageVersion already contains BuildNumberLabels in non-stable builds

[joeloff]

Another option might be to just leave the Version as is, but include $(_BuildNumberLabels) in the GuidInputs property so we end up with

<GuidInputs>$(Version);$(Platform);$(VersionSuffix);$(_BuildNumberLabels)</GuidInputs>

[dougbu]

Will changing the package filename confuse the dotnet/installer repo?

[wtgodbe]

Very possibly - I'll look into that now & see if I need to change anything there

[dougbu]

Would be nice if this were a public Arcade property. Ah well.

[wtgodbe]

@joeloff was this an issue with the aspnetcore-targeting-pack-x.y.z.msi (as opposed to aspnetcore-runtime-x.y.z.msi)? If so, that would mean we'd need to rebuild the targeting pack again... Otherwise that complicates the ingestion of this in dotnet/installer, because if we change the version of the targeting pack installer, we'd have to find a way to pin that non-stable version in dotnet/installer's dependencies for subsequent releases

[joeloff]

Highly likely. From what I can tell, both the targeting pack and runtime installer followed the same scheme. However, the two installers are grouped together as a single unit in VS. When the runtime fails, the targeting pack won't even be executed as VS suspends the rest of the execution plan after the first failure.

[Pilchie]

But - similar to the 2.1 PR, we don't have to ship the targeting pack NOW, right? We could just merge the fix so that it's there the next time we need to ship the targeting pack?

[wtgodbe]

@Pilchie we could do that, but we should still solve "how will dotnet/installer pin the version of the targeting pack .msi?" now, so we don't forget about it if/when we do eventually ship the targeting pack again. I can figure that out as part of my reaction PR in dotnet/installer

[wtgodbe]

Short of hard-coding a version in dotnet/installer, I think we'd have to start publishing a "microsoft.aspnetcore.app.ref.internal", similar to "microsoft.netcore.app.internal" (from dotnet/runtime), whose only purpose is to identify the non-stable ref pack version. It would only build when the ref pack is building. For now I think I'll hard code the current version in installer (3.1.2) as a property, and open an issue against myself to create the internal ref pack package for 3.1.6

[wtgodbe]

#21850 - issue for internal ref pack package

dotnet/installer#7487, dotnet/installer#7489 - reaction PRs in dotnet/installer