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

[Sean Hall]

> 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.

On Tue, Jan 12, 2021 at 5:41 PM James Parsons <Parsons.James at microsoft.com>
wrote:

> 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.
>