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

Tue Jan 12 15:40:58 PST 2021

Hi Sean,

Thank you for the quick feedback.

> On the other hand, if you think that people really want the answer to the

question "will my app run?" then I think this proposal should be for 6264

instead. 6257 should be about answering the question "is this software

installed?" for bundles and MSIs, and 6264 should be about answering the

question "will my app run?" for bundles and MSIs. The rest of this will

assume you wanted to go that direction.

We do think people want to answer the question "will my app run?". According to the .NET Core Releases and Support page (https://devblogs.microsoft.com/dotnet/net-core-releases-and-support/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdevblogs.microsoft.com%2Fdotnet%2Fnet-core-releases-and-support%2F&data=04%7C01%7CParsons.James%40microsoft.com%7C934fd70e71244231401008d8b7150aea%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637460648287690966%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=YrLAk3C%2BmqRRN0py3Y0c8MBu2Q%2F5m8BI34Od6caIoOg%3D&reserved=0>), "Current" releases are supported for up to 3 months after the next major/minor release and "LTS" releases are supported for just 3 years. In addition, there are monthly servicing updates that are out of support as soon as the next one is released.

It is important for developers to keep their applications supported and secure. The easiest way to do that with such short periods of support for current releases is to utilize roll-forward policies. With this in mind, the question "will my app run on this PC?" becomes more important than "is this software installed?". If there is a newer version of the release available, developers will want their application to use that version.

The NetCoreCheck tool (after some improvements) will allow applications that use roll-forward policies to accurately detect if the app will run on the target PC. Without this check, it's possible the installer would install a .NET release that the app doesn't even use when running. For example, if there’s a 3.1 app with roll-forward set to "LatestMajor" and it gets installed using this design on a machine with just 5.0, we would install the 3.1 runtime but then 5.0 would still be loaded when the app runs. It's also important to avoid the situation described in #6257 where an older patch version attempting to install over a newer one will fail.

To accommodate this behavior, I will modify the DotNetRuntimeSearch element to support an optional attribute for specifying roll-forward policies (Major-version roll-forward options for Core 3.0 · Issue #12237 · dotnet/docs (github.com)<https://github.com/dotnet/docs/issues/12237>). As there are a finite set of roll-forward policies, the attribute will be an enum in the schema.

It should be noted that the default roll-forward policy is "Minor":

"Minor -- Roll forward to the lowest higher minor version, if requested minor version is missing. If the requested minor version is present, then the LatestPatch policy is used."

And that setting the roll-forward policy to "Disable" could cause installations to fail if a higher patch version is present.

I will modify the WIP to target 6264 instead of 6257 as suggested.

> The long term goal for the Util.wixext searches (like util:RegistrySearch)

was to be able to use them in both bundles and MSIs. We haven't done that

yet, but that's why they're compiled by the Util extension instead of by

the core toolset. Where I'm going with this is that you should be able to

use the new element that you proposed for bundles in MSIs as well.

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?

> I don't think that DotNetRuntimeSearch is a good name for an element that

is answering the question "will my app run?". Maybe DotNetCompatibilityCheck?

I will change the name of the element.

> The element is missing the After attribute that is available for all searches.

I will add this element.

> All enumeration values like RuntimeType should start with a lowercaseletter, so I think it would normally be aspnet, desktop, core.

I will fix this.

> We need to support all the supported platforms for .NET 5 - x86, x64, andARM64.

lukewest has created an issue for creating an Arm64 version of the NetCoreCheck tool (https://github.com/dotnet/deployment-tools/issues/81<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2Fdeployment-tools%2Fissues%2F81&data=04%7C01%7CParsons.James%40microsoft.com%7C934fd70e71244231401008d8b7150aea%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637460648287690966%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=mX248rZ08yE1L0V1r8LfWU1Z0CX0Goj7hnb5ma%2FS8aY%3D&reserved=0>).

> If you're truly interested in answering that question, then NetCoreCheck needs

parameters to specify the app's roll-forward policy.

lukewest has created an issue for adding a roll-forward policy parameter to the NetCoreCheck tool (https://github.com/dotnet/deployment-tools/issues/82<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2Fdeployment-tools%2Fissues%2F82&data=04%7C01%7CParsons.James%40microsoft.com%7C934fd70e71244231401008d8b7150aea%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637460648287700955%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=uN5%2Broc%2BhWKiEDYEv8Sn9U9bpye4%2FYHOUP8GHpdNwys%3D&reserved=0>).

Thank you,

James

________________________________
From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> on behalf of Sean Hall via wix-devs <wix-devs at lists.wixtoolset.org>
Sent: Friday, January 8, 2021 2:18 PM
To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
Cc: Sean Hall <r.sean.hall at gmail.com>
Subject: [EXTERNAL] Re: [wix-devs] WIP 6257: Add DotNetRuntimeSearch to the NetFx extension for the detection of .NET Core/.NET 5 runtimes

Thanks for writing this up.

> I'm leaning towards the NetCoreCheck approach because it already exists,
has been validated, and answers the valuable question of "will my app run?"
instead of "is this software installed?".

I realize that we were debating back and forth in 6264 about which of those
questions should be answered, but for 6257 it is most definitely "is this
software installed?". As I noted in the issue, if a newer version of one of
the packages is already installed and the bundle tries to install it then
it will fail. In this case, the DetectCondition for the ExePackage really
needs to be true when the package is already installed or a future version
is installed that will cause the current package to fail. Going beyond
file/registry checks isn't the right thing to do here.

I'm not saying that this proposal is a bad idea and shouldn't be done, I'm
just saying that this is not the correct solution for 6257. Where we go
from here really depends on what your goals are.

If you really are interested in solving 6257, then I think we need to work
with the other guys in https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2Fsdk%2Fissues%2F15021&data=04%7C01%7CParsons.James%40microsoft.com%7C3a0c4e8e9fc94855cfa208d8b4235649%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637457411156720862%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CGlL8nMqi1Ypl85j2vW6zZLeV0aO0bm9jpUhOr0LywE%3D&reserved=0 so that
all of us can agree on the proper way to detect that a .NET Core runtime is
installed.

On the other hand, if you think that people really want the answer to the
question "will my app run?" then I think this proposal should be for 6264
instead. 6257 should be about answering the question "is this software
installed?" for bundles and MSIs, and 6264 should be about answering the
question "will my app run?" for bundles and MSIs. The rest of this will
assume you wanted to go that direction.

The long term goal for the Util.wixext searches (like util:RegistrySearch)
was to be able to use them in both bundles and MSIs. We haven't done that
yet, but that's why they're compiled by the Util extension instead of by
the core toolset. Where I'm going with this is that you should be able to
use the new element that you proposed for bundles in MSIs as well.

I don't think that DotNetRuntimeSearch is a good name for an element that
is answering the question "will my app run?". Maybe
DotNetCompatibilityCheck?

The element is missing the After attribute that is available for all
searches.

All enumeration values like RuntimeType should start with a lowercase
letter, so I think it would normally be aspnet, desktop, core.

We need to support all the supported platforms for .NET 5 - x86, x64, and
ARM64.

We could use these searches for the .NET Core packages until we have
implemented 6257.

These searches should definitely be in the NetFx extension. The
documentation you were referencing is end-user facing and is talking about
where the (v3) searches are, not where all searches are going to be.

Also I know you said NetCoreCheck was validated but as I said in 6264, I
don't believe that NetCoreCheck is properly answering the question "will my
app run?" because it's not taking into account roll-forward policies. For
example if an app compiled for 3.1 is configured for "Major" or
"LatestMajor", then it could run on a machine with only .NET 5. If it's
configured any other way it would not be able to run.  If you're truly
interested in answering that question, then NetCoreCheck needs parameters
to specify the app's roll-forward policy.

On Fri, Jan 8, 2021 at 2:35 PM James Parsons via wix-devs <
wix-devs at lists.wixtoolset.org> wrote:

> Hello everyone,
>
> I have created a WiX Improvement Proposal (WIP) to add a
> DotNetRuntimeSearch element to the NetFx extension for the detection of
> .NET Core/.NET 5 runtimes. Please review the proposal and provide any
> feedback you may have.
>
> web/6257-add-dotnet-runtime-search.html.md at develop · wixtoolset/web (
> github.com)<
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fwixtoolset%2Fweb%2Fblob%2Fdevelop%2Fsrc%2FWeb%2FStatic%2Fdocuments%2Fdevelopment%2Fwips%2F6257-add-dotnet-runtime-search.html.md&data=04%7C01%7CParsons.James%40microsoft.com%7C3a0c4e8e9fc94855cfa208d8b4235649%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637457411156720862%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=0uWNf02xGaCf3UIZIUvS%2BMWeN%2FACJAsFwPD3xQR3FYE%3D&reserved=0
> >
>
> Thank you,
> James
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.firegiant.com%2F&data=04%7C01%7CParsons.James%40microsoft.com%7C3a0c4e8e9fc94855cfa208d8b4235649%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637457411156730861%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Uopjy63%2Bozjco68xWsmcgEdspal7K33LI6UW8vCckMs%3D&reserved=0
>
____________________________________________________________________
WiX Toolset Developer Mailing List provided by FireGiant https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.firegiant.com%2F&data=04%7C01%7CParsons.James%40microsoft.com%7C3a0c4e8e9fc94855cfa208d8b4235649%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637457411156730861%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Uopjy63%2Bozjco68xWsmcgEdspal7K33LI6UW8vCckMs%3D&reserved=0