DOCS BUG: "Detecting and installing .NET" only says how to detect, not how to install

[BryanCrotaz]

https://wixtoolset.org/docs/tools/wixext/dotnet/#net-and-net-core

I want to install .Net 7 runtime if it's not already installed.

I can detect .Net 7 with:

<netfx:DotNetCompatibilityCheck
  Property="DOTNETRUNTIMECHECK"
  RollForward="major"
  RuntimeType="desktop"
  Version="7.0.0"
  />

Does this also detect high .Net 7 versions? Or only exactly version 7.0.0? The doc doesn't say. What value does the variable have if it's installed or not installed? True/false? Or the version number? It doesn't say.

Or I can detect .Net 7 in a bundle - huh? What's a bundle, and how is that different from what's above? Do I need to do both with an OR between them? The docs don't say.

Ok, so now I have detected them. No information here of what to do next. How do I install .net 7? How do I skip installing it if the variable has a certain value?

[wmanning]

About bundles.

Rob has a good explanation here: https://robmensching.com/blog/posts/2012/6/25/b-is-for-bundle-and-thats-good-enough-for-me/.
Allows you to combine multiple MSI packages into one installer, the user only sees the installer and the MSI becomes hidden details. I use it to install .net, driver MSIs, my main MSI, etc.

If you do use a bundle best is not to show MSI GUI at all, use the standard burn GUI (wixstdba I think it's called; you get it out of the box) or write your own custom burn GUI. There's ways to show the MSI gui through a bundle but at least in Wix 3.x it' was very problematic. Not sure about WiX 4.

[wmanning]

wixstdba also supports customization via a special theme xml file so you can add images and customize the look of the default burn installer.

<BootstrapperApplication>
      <bal:WixStandardBootstrapperApplication LicenseUrl="" SuppressOptionsUI="yes" ThemeFile="$(sys.CURRENTDIR)Theme\someTheme.xml" LocalizationFile="$(sys.CURRENTDIR)Theme\someTheme.wxl" Theme="hyperlinkLicense" />
      <Payload Name="someLogo.png" Compressed="yes" SourceFile="$(sys.CURRENTDIR)Theme\someLogo.png" />
      <Payload Name="anotherLogo.png" Compressed="yes" SourceFile="$(sys.CURRENTDIR)Theme\anotherLogo.png" />
      <Payload Name="icon.ico" Compressed="yes" SourceFile="$(sys.CURRENTDIR)Files\someIcon.ico" />
</BootstrapperApplication>

Tell burn the packages (MSI, EXE installers, etc) to install:

 <Chain>
      <PackageGroupRef Id="StandardInstaller" />
 </Chain>

which then can reference a bunch of packages (or just put everything directly in the chain):

<PackageGroup Id="StandardInstaller">
      <PackageGroupRef Id="dotNetInstaller" />
      <PackageGroupRef Id="Cpp_VS2013_Installer" />
      <PackageGroupRef Id="myMainInstaller" />
</PackageGroup>

Then say for your main MSI (myMainInstaller):

<PackageGroup Id="myMainInstaller">
      <MsiPackage Vital="yes" Compressed="default"  DownloadUrl="http://www.yourWebSite.com/folder/myMSI.msi" SourceFile="$(var.path)bin\Release\myMSI.msi" Name="data\myMSI.msi">
        <MsiProperty Name="APPDATADIRLOCATION" Value="[CommonAppDataFolder]myCompany\myAppName" />
      </MsiPackage>
</PackageGroup>

For .net, Wix comes with built in properties to pull in the appropriate EXE package into your chain. For me I needed some modifications (disable repair and do not cache) so I created by own package but even in that case wix has properties you can use to detect .net a least (the RegistrySearchRef below).

<util:RegistrySearchRef Id="NETFRAMEWORK40CLIENT" />
<?define NetFx40ClientRedistLink =  http://go.microsoft.com/fwlink/?LinkId=247730 ?>
<PackageGroup Id="dotNetInstaller">
      <ExePackage  Cache="remove" PerMachine="yes" DetectCondition="NETFRAMEWORK40CLIENT" Id="NetFx40ClientRedist" Vital="yes" Permanent="yes" Protocol="netfx4" DownloadUrl="$(var.NetFx40ClientRedistLink)" Compressed="default" Name="redist\dotNetFx40_Client_x86_x64.exe" SourceFile="$(sys.CURRENTDIR)\Files\redist\dotNetFx40_Client_x86_x64.exe" InstallArguments="/q /norestart /ChainingPackage &quot;[WixBundleName]&quot;" UninstallArguments="/uninstall /q /norestart /ChainingPackage &quot;[WixBundleName]&quot;">
      </ExePackage>
</PackageGroup>

[BryanCrotaz]

As per normal...

<util:RegistrySearchRef Id="NETFRAMEWORK40CLIENT" />
<?define NetFx40ClientRedistLink =  http://go.microsoft.com/fwlink/?LinkId=247730 ?>
<PackageGroup Id="dotNetInstaller">
      <ExePackage  Cache="remove" PerMachine="yes" DetectCondition="NETFRAMEWORK40CLIENT" Id="NetFx40ClientRedist" Vital="yes" Permanent="yes" Protocol="netfx4" DownloadUrl="$(var.NetFx40ClientRedistLink)" Compressed="default" Name="redist\dotNetFx40_Client_x86_x64.exe" SourceFile="$(sys.CURRENTDIR)\Files\redist\dotNetFx40_Client_x86_x64.exe" InstallArguments="/q /norestart /ChainingPackage &quot;[WixBundleName]&quot;" UninstallArguments="/uninstall /q /norestart /ChainingPackage &quot;[WixBundleName]&quot;">
      </ExePackage>
</PackageGroup>

Where did you get the magic incantation NETFRAMEWORK40CLIENT and all the paths and filenames from, and where in the docs is the equivalent for .Net 7?

[wmanning]

wix 3: https://wixtoolset.org/docs/v3/customactions/wixnetfxextension/
wix 4: https://wixtoolset.org/docs/tools/wixext/dotnet/
I guess you need the ".NET and .NET Core" section here: https://wixtoolset.org/docs/tools/wixext/dotnet/#net-and-net-core

Seems like you found this. FYI to others.
Like you said below it doesn't appear to be an entry to install .NET... Interesting. I"m still on the .net Framework so didn't realize that.

[BryanCrotaz]

Rather than having constants that need to be kept up to date, just have a string version number to compare against. For extra points, use npm style version comparisons. Eg ^2.0.0 means 2.0.0<=version<3.0.0

Then Wix doesn't need to keep up with Microsoft.

Then just point at the Microsoft download page for redistributables and document how in general to install a redistributable within your installer. Job done. Developer empowered.

[BryanCrotaz]

Rob has a good explanation here: https://robmensching.com/blog/posts/2012/6/25/b-is-for-bundle-and-thats-good-enough-for-me/.
It just says that a bundle can be made up of multiple msis. But it doesn't say how to do that.

From this doc:

On the other hand, if you are looking for a bootstrapper that does a "fire and forget" of one or more installation packages then a Bundle is not a good match.

I am literally looking for a fire and forget installer. I have an exe with its 4 dlls, some huge number of Microsoft dlls, and I want to install .Net framework and register it as a service. The only input will be the licence key. There are no features to choose from, no tiers, just a simple application. So I shouldn't be using Burn or bundles according to Rob - what should I be using instead?

[wmanning]

I would recommend bundles over doing a UI in MSI. More modern UI and then your MSI installers can be simpler. But then again, burn will be another thing you have to learn.

I think there use to be some advantage to having the installer as a MSI instead of an EXE if people (say IT) were doing unattended installation over thousands of machines but I don't know if that is still the case. (no experience myself, vaguely remembering someone mentioning in the mailing list long ago). Can anyone knowledgeable chime in on this?

[BryanCrotaz]

As far as I can understand a bundle is a collection of smaller MSIs. How is that a replacement for a UI? I'm really confused by all these different terms. In one place I read that bundles are good, another place they're bad. One place says use the cli, it's great, another I just read said that the cli is hard to use and heatwave is the thing to use.

Because the documentation is delegated to stack overflow and third party blogs (I was advised here to go and write my own documentation and self host just last week), all these sources are massively out of date with Wix, and contradict each other. It needs docs within the repo that are in sync with the code and are aimed at onboarding rather that people who know what they're doing or are upgrading from older versions (ie know what they're doing!)

[chrpai]

The evolution over the past couple decades has gone like this.....

We wanted to have just an .MSI but many machines did not yet have the Windows Installer service on them so a bootstrapper (setup.exe) was required to install the prerequisite before starting the MSI. This bootstrapper UI was typically a splash progress bar then executed the MSI which had it's own native UI. The MSI was typically monolithic: it had all of it's features and components in one package.

Then at some point MSI was already installed but now we needed other things like .NET Framework or C++ redist. The above pattern continued.

At somepoint we started to have things that needed to be installed along with the MSI but weren't 100% hard required. Instead of calling these prerequsites we called them chained packages. At this point the subtle difference between a bootstrapper and a chainer came to be.

Further along the line trying to manage upgrades and patches for a large monolitihic MSI became very hard so Microsoft started touting the concept of micropackages. Basically splitting 1 package into many of servicing them independently.

WiX and InstallShield then created their own tech to service these stories. InstallShield called them Suite Installers and WiX called them Bundles. WiX has an architecture where Burn, Bootstrapper Application, Bundle and so on have very specific meanings. Note that when you do this all of the UI and business rules are handled by your bootstrapper. All of the packages in the bundle are installed (or not installed) silently with parameters passed to them. The packages no longer need a UI at all. The bootstrapper also owns the add/remove programs entry and controls the UX for change, repair, uninstall.

At some point most of the really complicated apps started moving to the cloud. MSI was already on the machine. .NET / C++ was already on the machine or not needed. For many apps the above solution is no longer needed and is total overkill. We can just make a simple MSI and be done.

[chrpai]

@wmanning yes it is still the case. I work in EUC for a Fortune 20 company with over 200,000 windows devices. Pure MSIs are far simpler to ingest into systems such as SCCM, Intune and Workspace One. These tools have meta data similiar to what you see in a boostrapper... logic to detect if installed, logic to detect if needed, files, command lines and so on. Because a pure MSI is 100% declarativethe tool can automatically import the package. The EXE bootstrapper complicates this by hiding a lot of the internals so you have to go through additional steps.

I used to be the architect for this space but I decided to move on and do backend development instead. I do my own devops and consult on the side but otherwise I'm focused on more cloud centric technologies.

[wmanning]

Thanks for the confirmation.

We're probably a more extreme case. Our installer installs .net, a version of C++ redist, public cert, drivers, a main MSI containing our app, and a second MSI containing custom files that our app consumes.

I like burn as our software is sometimes critical to techs and they often are not computer savvy. We want to make it one seamless experience for them so we our installer contains everything to do the install just in case.

It is very nice being able to install the public cert first, in a separate MSI, to prevent windows popping up untrusted driver warnings to the user when installing the drivers.

[chrpai]

.NET Framework (2.0-4.8.1) or .NET ( 5-8)? There's a very important distinction here from a deployment perspective.

[BryanCrotaz]

Neither case is documented in the install case, and version 5-8 isn't documented in the detect case.

[chrpai]

What do YOU need?

[BryanCrotaz]

As per the OP, .net 7

[chrpai]

I was clarifying because you also said you wanted to install .NET Framework which is not 7. 7 is .NET.

My first suggestion is to consider switching to .NET Framework 4.x. Do you really need .NET 7? Are you multiplatform? Are there nuget packages your using that don't support .NET Framework or .NET standard? If there's no strategic or tactical reason then leveraging legacy .NET Framework really simplifies your installation because 99.99% of machines out there already have it. You just add a detect/gate check and block if it's not there.

If you must go .NET 7.... There's two ways of going about this:

1. Publishing your .net service as self contained so that it doesn't need .NET 7 installed on the machine. It just gets it's own private copy of .NET 7.

Pro: Simpler deployment (No .exe bundle needed - just a bunch of files), pinned version for compatibility
Con: Larger package, pinned version that you must service over the life of your application to get security updates. (Note: you have to do this with the rest of your nuget dependencies anyways)

2. Install .NET 7 if not installed
   Pro: Can have a smaller package (.exe bundle can call a web downloader), automatically gets updates from Microsoft
   Con: More complete installer (requires .exe bundle and see notes below), newer versions of .NET 7 could potentially break your application.

Note: WiX doesn't include examples of how to bundle .NET for a couple of reasons. The first is .NET is very fragmented now. There are 27 packages with every release of .NET. The second is .NET is releasing 1-2 times a month. We simply don't have the bandwidth to keep WiX up to date with that. I created a repos and asked interested people to contribute. No one did. Two months I implemented version 7.0.11 of the most likely needed package: .NET Desktop Runtime x64. It is already two versions old. Check it out at:

https://github.com/iswix-llc/IsWiX.NetCore/blob/main/Installer/IsWiX.NetCore/Net7/DesktopRuntime/DesktopRuntime-x64-7.0.11.wxs

[chrpai]

It really helps the search engine if you spell wixstdba correctly.

[wmanning]

My fault, will fix my original comment.

[BryanCrotaz]

correctly

Copied and pasted into search from the above reply...

[BryanCrotaz]

Publishing your .net service as self contained so that it doesn't need .NET 7 installed on the machine. It just gets it's own private copy of .NET 7.

Tried that but the service path is set up by <ServiceInstall/> with the Original Filename (an internal dll), not the actual filename (the wrapper exe). I tried every workaround I could think of but kept being stymied by Stuff.