NetFx PackageGroups should use WixVariables for DownloadUrls

[barnson]

• Describe the scenario and benefits that the feature supports.

Today, PackageGroups in WixNetFxExtension use preprocessor variables for DownloadUrls. They should use WixVariables instead, to make it possible to reuse WixNetFxExtension directly to host the downloads at different URLs (i.e., a CDN/S3/Azure blobs) to avoid Microsoft changing the payloads.

• Describe how you're accomplishing the feature today (if possible).

Copying/pasting WixNetFxExtension authoring.

• Describe what you'd like the new feature to do.

<WixVariable Id="NetFx48RedistLink" Value="https://go.microsoft.com/fwlink/?linkid=2088631" Overridable="yes" />
...
<ExePackagePayload Name="!(wix.NetFx48RedistPackageDirectory)ndp48-x86-x64-allos-enu.exe" DownloadUrl="!(wix.NetFx48RedistLink)" ...

[rseanhall]

I assume this is an alternative proposal to #6447 for addressing #6438. This would seem to require adding a new PackageGroup every time there's a new package because the hash would change. How would this proposal work with the latest 4.8 update? The URL and the version stayed the same, the signing certificate stayed the same, but the hash changed.

[robmen]

This seems like a useful standalone feature. It would make it much easier to self-host the .NETFX download and not have to duplicate all of the installation logic.

[rseanhall]

This feature would not work if NetFx only exposes one Net48Redist package with hash verification. We would have to update the hash every time Microsoft uploads a new package, which then would not match the package at the user's URL.

[barnson]

It's both.

[BMurri]

This feature would not work if NetFx only exposes one Net48Redist package with hash verification. We would have to update the hash every time Microsoft uploads a new package, which then would not match the package at the user's URL.

As I see what is being attempted here, the default case of using the extension is that the package is hosted somewhere other than Microsoft downloads, and the extension can then be revised every time MSFT touches their package, with a new URL (and hash or certificate, as applicable and if needed).

Since the variable is overridable, we would need to also expose the hash (or whatever) as a WixVar in the same manner, since then the author would be specifying the package to use.

[barnson]

Losing hashes makes this pretty low-value.