[wix-devs] [EXTERNAL] Re: WIP 6257: Add DotNetRuntimeSearch to the NetFx extension for the detection of .NET Core/.NET 5 runtimes

[Sean Hall]

>From https://github.com/wixtoolset/web/pull/59#issuecomment-765017538:

> @rseanhall I kept the WIP targeted at #6257 because I believe the
DotNetCompatibilityCheck element should be used in NetCore3_Platform.wxi to
replace the current .NET runtime detection strategy which has the problem
that #6257 describes.

> I don't mind that it's retargeted to #6264 as long as you're aware of my
plans moving forward. It should also be noted that this WIP doesn't contain
any specific proposals related to custom actions/launch conditions even
though the DotNetCompatibilityCheck can be used for that purpose.

I feel like there's some major miscommunication happening here.  Like I
said before, we can use your proposed searches for the .NET Core packages
until we have implemented 6257. While it may be up for debate whether users
will want the answer to the question "is this software installed?" or "will
my app run?", we never had any question about what to ultimately use for
the bundle searches in the NetFx extension.

The bundle's job is to install its packages. The design of Burn is that
each package needs to be detected as installed or not. If it is already
installed, then it must not try to install it. Therefore, it is very
important that the DetectCondition answers the question "is this software
installed?", and not "will my app run?". If the product is installed but
somehow corrupted to where the NetCoreCheck tool can't detect it, then the
bundle will fail unnecessarily. The user may not be able to run the app,
but that's beyond the scope of the installer. If the bundle is concerned
with this scenario, then it could always decide to repair .NET Core. By the
way, it's perfectly legal for a bundle not to have an app, or to contain
multiple apps.

In WiX, we try to provide building blocks for the user to be able to
assemble their installer. For example, in searches our goal is to help the
user determine the presence of something. It's up to the user how to
handle the result. We never had built-in launch conditions for .NET
Framework, so that would be an interesting question if that's something we
want to maintain for .NET Core.

On Thu, Jan 14, 2021 at 11:58 AM Sean Hall <r.sean.hall at gmail.com> wrote:

> > Could you elaborate on how to use a common element between bundles and
> MSIs? Are there special considerations if the element is within a Fragment?
>
> If the parent is a Bundle, compile it for a bundle. If the parent is
> Package or Module, compile it for MSI. If the parent is Fragment, compile
> it both ways. In v4, each backend extension will need to ignore the symbols
> created for the other output to avoid warnings. And after thinking about
> it, knowing what to ignore might not be simple because it would link in
> other things.
>
>>
>>