Managed Bootstrapper with Prerequisite NETFX Redist Install before Bootstrapper WiX v5

[MeikTranel]

Hey,

we are currently migrating from WiX v3 to v5 and thus have some questions regarding our current setup.

Basically we have a custom WPF bootstrapper which used to be hosted but is now a standard windows application which leaves us in change of the runtime we run on.

As it turns out we found out that installing .NET Framework 4.8 before starting the bootstrapper never really worked as we just found out that our runtime config just hosted it in the next best NETFX 4.0 CLR that is installed on the system (no Sku given in app.config/bootstrappercore.config supportedRuntime entry).

We found out about this because the new winexe now comes with a autogenerated app.config that does indeed set the Sku and presents systems without it installed a harsh error dialog with a redirect to the .NET Framework download page. The bundled netfx48 installer was never touched.

I've been trying everything really to indicate to the WixSDK that the installer needs to run before the Bootstrapper starts but to no avail.

Can y'all give me a hint if this is even a supported scenario and how that is supposed to work as WXS goes?

[bevanweiss]

One idea might be to use the standard WiX bootstrapper to do the pre-req install, and to then have it launch your bootstrapper as an EXE package.

So the WiX bundle would just have the pre-req for .NET, and an EXE package for your bootstrapper.
I'm unsure if nesting bootstrappers is actually allowed... but it seems like a simple idea.

Another option might be to have a native DLL which is your primary BA, and hence requires no .NET
Have this handle as much of the startup process as possible to get through the pre-reqs phase. Then you could use something like LoadLibrary to bring in your WPF DLL once the .NET requirements for that portion have been met. Unfortunately you couldn't just let the default Windows dependency linking do it's job, since then it would try to bring in the .NET references at startup, which would cause your current problem.

I've never tried to dynamically bring in a .NET DLL following installation of the .NET Pre-requisites... so I'm unsure how the environment setup around it works (or does not work as the case may be...), DLL search order might need some manual handling...