Core: Questions / Concerns over .NET Core Desktop Deployments

[gortok]

General

With the advent of Winforms support in .NET Core 3.0, there are now three deployment models, "Self Contained", "App Local" and "Computer wide".

I'll define them as I understand them, and would love any corrections to this:

Self Contained: .NET Core is bundled with the application being deployed, no machine knowledge or generalized access understanding to this version of .NET Core - (It's not installed in "Program Files")

App Local: Provides Machine visiblity into the version of .NET Core being installed (Installed in Program Files), but each version gets its own directory and so .NET Core applications already on the machine depending on another version of .NET Core are not affected.

Machine Wide: As it is today: One copy of .NET Framework is installed, and generally updated. Everyone is affected when this is updated.

My questions mostly mirror the tenor of the questions found in #1781, #1541, core-setup #4778, #501. It's important to note that as of yet, I don't see any resolution in any of those issues about any of the questions raised.

If I use Self-Contained Deployment for my .NET Core Winforms Desktop application, who has responsibility to update the version of .NET Core if there are any zero-day patches required? Me? Microsoft? The End User's IT Team?

Is there tooling around automatic .NET Core version updates? Or is this tooling we'll need to create ourselves? (a la, if we're using WIX or installshield, do we need to provide the update binaries for .NET Core)

For App Local, who is the primary party responsible for updating when there are .NET Core Zero-day exploits or new security patches? Is it the end-user? Is it the application developer? Is It Microsoft via Microsoft Updates?

Have any of these assumptions changed for Machine Wide deployments? Who is the primary person responsible for updating .NET Core in that case? The application developer (probably not), the End User, or the IT Team?

In ASP.NET Core, a version of Curl changed (this was April of 2017), and it caused a 40x slowdown in performance for POSTing via .NET Core. Ultimately the update required a change to the .NET Core Docker container image, and in corefx itself. How will we handle those changes in this new world of Self Contained Deployments? Do Self-Contained Deployments also refer to machine level packages like libcurl? or are these libraries also bundled in each .NET Core SCD? (Recognizing that currently Winforms is only available for Windows; I'm thinking particularly of Console applications).

There exists a cottage industry of applications that scan the local system for out of date libraries and frameworks. (One such example is Tanium. I saw another in my travels last week but cannot remember its name). How will Self-Contained Deployments affect this industry? Will there be API hooks where each SCD registers itself with the OS to allow for scanning? OR will these scanning applications now need to effectively scan all binaries on the system?

All of these questions apply to console applications on MacOS and Linux now for .NET Core now; short of ones I've written, I don't know how many of these exist in the wild besides my own.

If all of those previous issues as well as the questions I'm posing have been answered, please let me know -- I searched but did not see any resolution.

TL;DR Questions:

1. What is the .NET Foundation's (or Microsoft?) official patching and vulnerability update strategy guidance for .NET Core Self-Contained Deployment Console (x-plat) and Desktop Applications (Windows Only)? Is it completely on the vendor? Or is there API access so the IT Team / Third Party Patch Management Vendors have access to the fact that a SCD is present and at a vulnerable version of .NET Core?

2. What is the .NET Foundation's (or Microsoft?) official patching and vulnerability update strategy guidance for .NET Core App Local Console (xplat) and Desktop Applications (Windows Only)? Is it the responsibility of the IT Team or the Vendor that applies the .NET Core download? What should happen to previous versions of the .NET Core framework. Should they be uninstalled?

3. What is the .NET Foundation's (or Microsoft?) official patching and vulnerability update strategy guidance for .NET Core Machine Wide Console (xplat) and Desktop Applications (Windows Only)? Is it the responsibility of the IT Team? The vendor that provides the download? What is the official backwards-compatibility story if we have an older .NET Core application and the IT Team updates the machine wide version due to a vulnerability?

4. For instances where dependencies change from underneath .NET Core (for instance, libcurl); what is the patching and management strategy for these changes? We have had instances where changes to underlying "OS level" libraries and packages have had adverse affects on .NET Core (the classic case was the 40x slowdown in POSTing to an ASP.NET Core endpoint due to a TCP_NODELAY issue with libcurl). What is the official guidance for this? Should vendors be tracking these issues for update? Will these updates be noted in releases for .NET Core? How will these changes be packaged for Desktop Deployments?

[karelz]

Related to #1541?

[karelz]

@richlander can you please help route it? (ot let me know who else can help with it, thanks!)
cc @dleeapho @shawnro @leecow

[p6345uk]

@gortok @karelz

Quick related question.

I am using IIS to host My .net core app and when i install this i have to update, i have to update both the runtime and the hosting bundle. i cant seem to find an independent hosting bundle.

In this situation the Self contained option seem totally pointless.

Also from experience this required a reboot once its installed (Lets you know after you have installed it).

[richlander]

We are consider putting a .NET Core framework package in the Windows Store. If we did that, it would be updated every patch tuesday, such that apps that had a dependency on the framework package would always be up to date. There would be a framework package for each .NET Core version, like 3.0 and 3.1, such that applications would not be automatically updated to a new version. Such a plan would only apply to Windows 10.

If we enabled such an experience, would that satisfy your need and would you use it?

[csturm83]

@richlander, would such an experience address the enterprise scenarios described by @JaredShaver in #1541?

If not, can mechanisms similar/same to what's available for .NET Framework enterprise deployments be made available for Framework-Dependent Deployments?

[JaredShaver]

@richlander how does this help Windows Server or enterprise desktops that have the store disabled. Microsoft already has enterprise patching tools(WSUS/SCCM) ... please just support what already works. A huge part of the .NET Core story has been not supporting a feature then backtracking and re-doing things that .NET Framework originally did.

[csturm83]

A huge part of the .NET Core story has been not supporting a feature then backtracking and re-doing things that .NET Framework originally did.

Agreed. Please consider supporting an enterprise friendly (preferably familiar) deployment/update mechanism.

Also, please consider bringing full WCF to .NET 5 (or at least contribute the source to the .NET Foundation/community).

[Bartolomeus-649]

@richlander

We are consider putting a .NET Core framework package in the Windows Store. If we did that, it would be updated every patch tuesday, such that apps that had a dependency on the framework package would always be up to date. There would be a framework package for each .NET Core version, like 3.0 and 3.1, such that applications would not be automatically updated to a new version. Such a plan would only apply to Windows 10.

If we enabled such an experience, would that satisfy your need and would you use it?

We do NOT run/use the store on all our clients.

We do all Windows updates via SCCM.
We need to be in 100% control of the update process, individual clients cannot go out on the internet and just download something we don't know what it is and install is!

We have applications that need to run on Windows Client Desktops, but without any end users ever touching the machine. They are run as if they were a server.
There are several reasons for this, for example because the application can only be installed on Windows client desktop.
We also have a huge amount of Windows 7 machines who are not going anywhere soon.

Distribution need to be done via Windows Update!

[carlossanlop]

This seems to be a duplicate of https://github.com/dotnet/core/issues/1541
Let's move the discussion there.