Completely lost with installing core runtime (dotnet 8)

[Lindsay-Mathieson]

Have the main installer sorted - does my desktop app and service

Want to have it optionally install the dotnet 8 desktop & asp.net runtime and for the life of me can't figure out where to start, I know it involves something to do with "bootstrapping" but all the docs/examples I find online are old, incomplete and seem to assume a lot of prior knowledge or are so massively complicated, installing exercising every feature that I can't decipher what is happening.

Can anyone point me to a simple working sample of say installing a dotnet 7 or 8 runtime before the main installer?

This simple command line does all that I want:

winget install --silent --accept-source-agreements --accept-package-agreements dotnet-desktop-8 aspnetcore-8

But I can't invoke it from the installer as that would nest the msiexec process.

Thanks.

[NJullienSweet]

I'm also installing .NET 8 on my side. I'm using a bootstrapper indeed.

To do so, I'm creating an ExePackage and specifying the URL where the user machine will be able to download the installer. You have also have to supply the installer's hash and its size to make sure that the machine has the one you intended to install.

const string DotnetRuntimeDownloadUrl = "https://download.visualstudio.microsoft.com/download/pr/b280d97f-25a9-4ab7-8a12-8291aa3af117/a37ed0e68f51fcd973e9f6cb4f40b1a7/windowsdesktop-runtime-8.0.0-win-x64.exe";
(var hash, var size) = await GetHashAndSizeAsync(DotnetRuntimeDownloadUrl);

var dotnetInstaller = new ExePackage
{
	Id = "DotNet8",
	InstallArguments = "/install /quiet /norestart",
	RepairArguments = "/silent /repair /norestart",
	UninstallArguments = "/silent /uninstall /norestart",
	PerMachine = true,
	DetectCondition = "DOTNET_RUNTIME_CHECK >= v8",
	Payloads = new Payload[] {
		new ExePackagePayload
		{
			Name = "windowsdesktop-runtime-8.0.0-win-x64.exe",
			DownloadUrl = DotnetRuntimeDownloadUrl,
			Hash = hash,
			Size = (int)size.Bytes
		}
	}
};

// specifying dotnetInstaller then yourMsiHere will make sure to install these in this exact order.
var bundle = new Bundle("BundleName", dotnetInstaller, yourMsiHere);

// Rest of your WixSharp setup

The DetectCondition (DOTNET_RUNTIME_CHECK >= v8) results of this:

// Adds .NET compatibility check to the bundle.
bundle.AddXml("Wix", new DotNetCompatibilityCheck(
	"WindowsDesktopRuntimeCheck",
	"DOTNET_RUNTIME_CHECK",
	DotNetCompatibilityCheck.RollForwardPolicy.LatestMinor,
	DotNetCompatibilityCheck.RuntimeType.Desktop,
	Platform.x64,
	new Version(8, 0, 0, 0)).ToXmlFragment());

[NJullienSweet]

When I try to make it a WixEntity I'm ending up with errors about a generated DotNetCompatibilityCheckRef and I don't really have enough time to fix it today, so I'll wait for your own official version! 😁
Glad I could help though!

[oleg-shilo]

Not a prob. Will do.
DotNetCompatibilityCheckRef might be caused by not having bundle.Include(WixExtension.NetFx), but I will see.

[oleg-shilo]

No, I was wrong. The problem is caused by WixExtension.NetFx not feigning DotNetCompatibilityCheckRef element which seems to be the normal way of integrating Fragment elements. IE as for ProductSearch:

however in case of DotNetCompatibilityCheckRef it throws the error:

Thus if one wants to use your approach but with the very current WixSharp the working code is:

bundle.AddXml("Wix", new XElement("Fragment", new DotNetCompatibilityCheck(
    "WindowsDesktopRuntimeCheck",
    "DOTNET_RUNTIME_CHECK",
    RollForward.latestMinor,
    RuntimeType.desktop,
    Platform.x64,
    new Version(8, 0, 0, 0)).ToXElement(WixExtension.NetFx.ToXName("DotNetCompatibilityCheck"))).ToString());

But of course, I am going to allow a more natural approach:

bundle.AddWixFragment("Wix", new DotNetCompatibilityCheck(
    "WindowsDesktopRuntimeCheck",
    "DOTNET_RUNTIME_CHECK",
    RollForward.latestMinor,
    RuntimeType.desktop,
    Platform.x64,
    new Version(8, 0, 0, 0)));

[oleg-shilo]

Done.
Release v2.4.1

---

There are now various ways to add the DotNetCompatibilityCheck to the bundle as XML but this is the recommended one:

var check = new DotNetCompatibilityCheck(
    "DOTNET_RUNTIME_CHECK",
    RollForward.latestMinor,
    RuntimeType.desktop,
    Platform.x64,
    new Version(8, 0, 0, 0));

bundle.GenericItems.Add(check);

[Lindsay-Mathieson]

(var hash, var size) = await GetHashAndSizeAsync(DotnetRuntimeDownloadUrl);

Do you have the src for this function? Does it read the hash and size from the page directly?

Currently I'm implementing it by actually downloading the file can calculating them, but that seems sub optimal.

[Lindsay-Mathieson]

Fantastic stuff, carving out some time this weekend to test it.

Related question - when installing dotnet runtimes as dependences of our apps, should we really be uninstalling them as part of our apps uninstaller?

[Lindsay-Mathieson]

Is there a way for a bundle to invoke an command on the pc, rather executing an included or remote installer?

I'd like to just run

winget install --silent --accept-source-agreements --accept-package-agreements dotnet-desktop-8 aspnetcore-8

Which installs the latest dot 8 components, rather than download and execute a specific dotnet 8 version

[Lindsay-Mathieson]

Have a working bootstrap exe, that installs dotnet desktop and asp runtimes - thanks very much

It also installs my MSI, but none of my managed dialogs are showing, just the generic license screen, which I had disabled.

My MSI Package

            var msiPackage = new MsiPackage(builtProject)
            {
                DisplayInternalUI = true,
                EnableFeatureSelection = true,
            };

and the setup I have

            project.ManagedUI = new ManagedUI();

            project.ManagedUI.InstallDialogs.Add(Dialogs.Welcome)
                                            //.Add(Dialogs.Licence)
                                            //.Add(Dialogs.SetupType)
                                            .Add(Dialogs.Features)
                                            .Add(Dialogs.InstallDir)
                                            .Add(Dialogs.Progress)
                                            .Add(Dialogs.Exit);

            project.ManagedUI.ModifyDialogs.Add(Dialogs.MaintenanceType)
                                           .Add(Dialogs.Features)
                                           .Add(Dialogs.Progress)
                                           .Add(Dialogs.Exit);

[oleg-shilo]

Unfortunately, WiX does not have support for showing MSI UI that is not a native MSI UI but a custom managed UI defined by the user. In MSI terminology such UI is called EmbeddedUI. This is the UI type you are using.

WiX has had this bug since v3 (wixtoolset/issues#4921) and sadly with WiX4/5 there is still no way to solve this problem directly.

Thus your options are rather limited and they are:

• Follow 'WixBootstrapper_MsiEmbeddedUI' sample, which shows a very simple technique of wrapping msi into a self-hosted executable included in the bundle that happily shows the MSI UI regardless of whether it is a native or a managed one.

• Use NSIS bootstrapper instead. Sadly. WiX Bundle seems to be too fragile and inflexible.

• If the only reason for using a bootstrapper is to do a few simple actions (e.g. assess the environment) before product installation, then you can use an incredibly simple bootstrapper/launcher that is a pure custom CLI application. See 'Self-executable_Msi' sample.

[Lindsay-Mathieson]

• Follow 'WixBootstrapper_MsiEmbeddedUI' sample, which shows a very simple technique of wrapping msi into a self-hosted executable included in the bundle that happily shows the MSI UI regardless of whether it is a native or a managed one.

Thanks, that worked well for me.

See 'Self-executable_Msi' sample.

Interesting, thanks, will assess that, since I just want to run winget

[oleg-shilo]

BTW, 'WixBootstrapper_MsiEmbeddedUI' involves building 'Self-executable_Msi' as an authoring step. Thus both samples are very related.
It's just one gives you the opportunity to have some "free-style" routine in the 'Self-executable_Msi' exe and another sample takes that exe into a bundle the traditional way.