Docs page showing how to bundle .NET 6+

[jnm2]

I've been reading the WiX v4 docs and searching the internet on multiple occasions, and it's not clear what the equivalent method would be to start using .NET 6 instead of a .NET Framework package group. I saw https://github.com/orgs/wixtoolset/discussions/7381#discussioncomment-5567881. It explains the reasons that the WiX maintainers don't want to ship the same kind of support for folks who depend on .NET shared runtimes. That makes sense. In this case, could you please have a page with sample code and steps describing what to do in order to implement it yourself? What are people doing today? What is recommended?

https://wixtoolset.org/docs/tools/wixext/dotnet/#net-and-net-core seems like a good place for this content, or from which to link this content.

I'd be happy to contribute the docs myself and I'm absolutely willing to get my hands dirty, but I'm still lacking a starting point and I'm sure I'd miss some subtleties that would turn out to be important in a docs page that would become an essential resource for many apps. What's a way to implement this in WiX v4 that would be of interest to folks who are coming from the NetFx48Web package group (for instance) and moving their app to .NET 6+?

[chrpai]

I've thought about making an extension and publishing to nuget to support this but honestly .NET is shipping every month these days. I have personally found it easier to just setup a publish profile for my app and deploy it with a private copy of .net. This avoids the need for a bootstrapper and in a corp environment that's a good thing because MDM tools handle MSIs easier. It does mean even my tiniest apps are a few dozen MBs in size but it's not the end of the world.

[jnm2]

The private copy has a downside of not getting security updates through Windows Update.

I know the author of Paint.NET did something to make the equivalent of a web downloader for the newest available .NET runtime within a certain range. Maybe that's the key?

[chrpai]

Paint.NET also went to the Windows Store. I don't want to pay the $9.99 to find out but I'm betting if I download the package it contains .NET core inside it.

Belly up to the bar and I'll pour us a cold one. We could talk in person for hours on this topic. Windows Update only services .NET runtime as an opt-in. Ok, so .NET is up to date... what about all those nuget dependencies your app is using? Ya hear you... I get it. Two pendulums have swung here...... global to local and waterfall to agile. I am not against what you are saying, but I am saying it's a lot of automation that is needed to keep up with that team.

At my day job we have cicd pipelines and static code scanning for vulnterabilities. I have stuff on windows and in containers. The concept of having to constantly be aware of vulnerabilities in production and service them is forefront in my mind. With local copy I simply keep my build servers up to date and frequently deploy my apps and they are kept up to date. With code scanning I get alerted to update my nuget packages and they are kept up to date also.

Here's an example of what authoring in wix looks like. 6.0.2 was released on Feb 8, 2022. Since then there have been 20 additional releases. This is just the desktop. There are many other prereq packages that they release at the same time.

If you can think of a way to automate this and have a PackageRef="DotNetDesktop6Latest" I'm all ears.

	<util:RegistrySearch Id="findDOTNETVersion" Root="HKLM" Key="SOFTWARE\dotnet\Setup\InstalledVersions\x64\sharedhost" Value="Version" Result="value" Variable="DOTNETVERSION" Win64="yes" />
		<util:RegistrySearch Id="findDOTNETDesktop" Root="HKLM" Key="SOFTWARE\dotnet\Setup\InstalledVersions\x64\sharedfx\Microsoft.WindowsDesktop.App" Result="exists" Variable="DOTNETDESKTOP602INSTALLED" Win64="no" />
<ExePackage Id="DotNetDesktop602"						 
                  DownloadUrl="https://download.visualstudio.microsoft.com/download/pr/efa32b7a-6eec-4d97-9cdc-c7336a29a749/3df4296170397cf60884dae1be3d103b/windowsdesktop-runtime-6.0.2-win-x64.exe"
                  Name="Windows Desktop Runtime Environment - 6.0.2 (x64)"
                  InstallCommand="windowsdesktop-runtime-6.0.2-win-x64.exe /install /quiet /norestart"
                  RepairCommand="windowsdesktop-runtime-6.0.2-win-x64.exe /repair /quiet /norestart"
                  UninstallCommand="windowsdesktop-runtime-6.0.2-win-x64.exe /uninstall /quiet /norestart"
                  DetectCondition="DOTNETDESKTOP602INSTALLED and DOTNETVERSION >= &quot;6.0.2&quot;"
                  SuppressSignatureVerification="yes"
                  Permanent="yes" 
				  Vital="no">
				<RemotePayload CertificatePublicKey="13D6BFE4ADC9AD828EC78546ECEDE746B44C863F" CertificateThumbprint="921263EA40B2C7592E8CC1C1A4EF66E64D511674" Description="Microsoft Windows Desktop Runtime - 6.0.2 (x64)" Hash="EA8DB9D01555D0EA2A3D3CD41D56A28199A064F5" ProductName="Microsoft Windows Desktop Runtime - 6.0.2 (x64)" Size="57296456" Version="6.0.2.30914" />
			</ExePackage>

[chrpai]

@jnm2 if I created a repos that built a wixlib, would you maintain it with me?

[jnm2]

I wouldn't mind helping as a maintainer if I use this myself. Let me understand what it does though. I'm looking for:

1. Distinguish the desktop runtime versus other runtimes (console-only or web runtimes?)

2. If possible, web install. That means downloading the runtime only if needed. The app itself might have RollForward of LatestMajor for instance, and then the presence of 7.0.x installed on the machine would mean we skip installing 6.0.x even if the app targets 6.0.

3. Dynamically discover and install the latest patch version of the runtime within a given major/minor version sequence. The Paint.NET author described doing this in a Twitter thread a while back that I could dig up. https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-install-script exists, but it's for CI scenarios and not for production deployments; nonetheless, it could hold clues to the autodiscovery part.

4. If possible, the runtime uninstalls when the app installs (reference-counting, if more than one app depends on it). I don't know how to do this yet but I think I've seen it done with other dependencies between apps.

If these things sound possible, I'd be interested in maintaining something that encapsulates this functionality.

[chrpai]

I went ahead and created this repos https://github.com/iswix-llc/IsWiX.NetCore and published release v1.0.0 containing the wixlib. Currently the supported PackageGroupRefs are DotNetDesktop6022Redist and DotNetDesktop7011Redist. Course now that I type this I realize I should have but bitness in their names.

If you don't want to help with this and just want 6+ without pulling down a wix lib you can find the fragment here https://github.com/iswix-llc/IsWiX.NetCore/blob/main/Installer/IsWiX.NetCore/Net6/DesktopRuntime/DesktopRuntime-x64-6.0.22.wxs

It is totally self contained. Just add a reference to NetFx for DotNetCoreSearch to function.

[chrpai]

My implementation currently does 1 and could be extended to support 2. 3 is a pretty complex beast that would need custom code outside of what WiX currently can do. 4 isn't possible or really advised. Things like .NET and C++ runtimes are best left installed forever. There is no universal mechanism for knowing if anything installed on the machine needs them.