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

[James Parsons]

Hi Sean,

Thank you for clearing up the miscommunication.

Like you suggested in an earlier email, I will reach out to the owners of Up to date check proposal · Issue #15021 · dotnet/sdk (github.com)<https://github.com/dotnet/sdk/issues/15021> so that we can all agree on the proper way to detect that a .NET Core runtime is installed for #6257.

In the meantime, I will work on creating the DotNetCompatibilityCheck element for bundles and fragments.

I also spoke with MSLukeWest about the built-in launch conditions for .NET Core and we agree that it is unnecessary at this time.

Thank you,
James
________________________________
From: Sean Hall <r.sean.hall at gmail.com>
Sent: Thursday, January 21, 2021 5:05 PM
To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
Cc: James Parsons <Parsons.James at microsoft.com>
Subject: Re: [EXTERNAL] Re: [wix-devs] WIP 6257: Add DotNetRuntimeSearch to the NetFx extension for the detection of .NET Core/.NET 5 runtimes

>From https://github.com/wixtoolset/web/pull/59#issuecomment-765017538<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fwixtoolset%2Fweb%2Fpull%2F59%23issuecomment-765017538&data=04%7C01%7CParsons.James%40microsoft.com%7Cc71d10d3de9148a8ddeb08d8be71c8c0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637468743198835961%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hr1%2BVJGLuxmIfNHl51X9VnMMglf8rhLV39QmRJigLbM%3D&reserved=0>:

> @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<mailto: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.