Include the .NET Core runtime as default Windows 10 component

[BieleckiLtd]

Windows 10 May 2019 Update (all editions) includes the most recent .NET Framework 4.8 as an OS component, and it is installed by default.

In the corporate environment it is a great hurdle to convince IT to install anything that is not included in the default installation package. To enable framework-dependent deployment please include the .NET Core and .NET Core Desktop Runtime and as Windows 10 component - same as the (main?) Framework.

[scalablecory]

Our recommendation here is to create self-contained applications and not depend on the .NET Core runtime being installed separately.

You could also have IT manage updates to the .NET Core runtime as they would any other application.

[ChayimFriedman2]

@scalablecory But Windows is anyway big, and that could save space and more importantly angry customers. Assuming most of users won't install, or even herd about .NET Core until they'll use a program that requires it, it seems natural for me to include a copy of the runtime with the OS so that running .NET applications will be a seamless experience.

[lcsondes]

Also download size. I've had resistance from users who looked at the 70+ MB file size of a self-contained application and called it bloated, etc. and didn't want to use it. They then start to associate this with .NET itself which itself becomes a hurdle.

The same application back when it was on Framework could fit on a (theoretical) floppy and you could be absolutely certain that it would work on any Windows 7/10 within the company.

[lellid]

I fully agree. Maintainability is also an issue here (see #5013). Additionally, self contained distributions have limitations (x86 / x64 flexibility, COM servers etc.).

If you are not willing to distribute .NET Core and .NET Core Desktop Runtime as a default part of Windows 10, then at least consider allowing a normal user (non-admin) to add these components manually.

[SirUppyPancakes]

Yeah 200mb+ deployments are flat out unacceptable in my opinion, especially if you're distributing multiple independent apps. Coming over to WPF on NET Core from NET Framework, I have to say that knowing that my pretty much 100% of my users are going to be running into the new "you need to install NET Core to run this app", as opposed to before where only the offline users or those who didn't run windows updates enough would hit it, is super discouraging. (Thank god the popup at least exists now though; I can't believe you guys thought that doing nothing and letting Event Viewer catch the error was somehow an acceptable default experience oof)

At the very least, as lellid mentions, an official installer/script meant for non-admin end-user deployments would go a long way towards helping us devs create acceptable deployment experiences for our users. It seems like this sort of idea is at least on your guys' radar to some extent (dotnet-install), and I had initially thought this was going to help me deploy to end-users until I read that it's for development scenarios like Continuous Integration and not end-user deployment (dotnet/docs#18715). Honestly, it seems like this could be branched with some minor tweaks as an official way to deploy NET Core to end users as a requirement for your app, without the user ever having to know/worry about it at all (the whole point of an installer).

[jamshedd]

.NET Core is not a component of Windows, and there is no plan to move in that direction. Making .NET Core a component of Windows would mean .NET Core would be the same as .NET Framework including the very high compat bar which can sometimes prevent us from making changes or adding features as fast as we'd like to. If you really need .NET bits to be part of the shipping Windows OS then I'd recommend sticking to .NET Framework.

That said, we are working on making it easier to deploy .NET Core updates across an enterprise in the future. In the near future (couple of months) we will start delivering updates for .NET Core 2.1, 3.1 and 5.0 via Microsoft Update so you don't have to repackage and deploy this yourself. I am using the term MU loosely here, the support will include end user MU updates, as well as WSUS and MU Catalog (which enable SCCM too). Basically all the typical tools used in an enterprise IT setting can be used to deploy .NET Core updates with nearly the same experience as current updates for .NET Framework. This work is tracked by another issue: #5013 (comment), we will use that for updates.

Since this issue is about shipping Core as a Windows component that is not a direction we plan to go in I will be closing down this issue.

[legistek]

My application is now 3x the size to download and update. Thanks guys,.