Will .Net 6 come pre-installed in Windows 11?

[shrinidhi111]

No description provided.

[krwq]

cc: @terrajobst

[krwq]

My guess is no, according to: #6389 (comment)

[shrinidhi111]

It'll great if so though, many clients are unhappy with installing additional runtimes so we are forced to limit our development to whatever framework is most common

[terrajobst]

No. We don't have any plans to bundle .NET into the OS and we're trying really hard to avoid this.

[terrajobst]

It'll great if so though, many clients are unhappy with installing additional runtimes so we are forced to limit our development to whatever framework is most common

Consider doing a self-contained deployment. Also, .NET 6 comes with a much improved linker.

[Sebazzz]

It'll great if so though, many clients are unhappy with installing additional runtimes so we are forced to limit our development to whatever framework is most common

Then make a self contained deployment. Then it is not a runtime, but part of the program.

Just like you can static link a Visual C++ runtime.

[poke]

@terrajobst

we're trying really hard to avoid this.

The usual reasoning I hear behind this is that shipping it with the OS means that it is bound to the same update cycles as the operating system. However, there are multiple examples that contradict this. For example the Calculator app and notepad which are both bundled with Windows but were somewhat recently announced to receive updates through the Windows Store.

There also is a separate thing that already makes it possible to receive updates for .NET Core via Microsoft Update, independent of the operating system.

So why is it not possible to ship .NET Core with the operating system while also providing OS-independent updates through one of these channels? Or at least have some kind of shim like that super weird python executable that triggers an install via the store.

Having a runtime installed by default would really help the adoption of .NET (Core) in the desktop space. Yes, it is possible to have self-contained deployments but that also means dealing with application sizes way above 50 MB which is a lot, especially for simpler applications (and no, AOT isn't there yet).

For what it's worth, I still build smaller WinForms or WPF applications using the .NET Framework because it can be shipped a lot easier and usable on every Windows machine by default. But it's sad that I have to do this.

[Szer]

No. We don't have any plans to bundle .NET into the OS and we're trying really hard to avoid this.

Does it mean that even .NET 4.X won't be bundled in Win11?

[davidfowl]

This is about .NET (5/6, etc), not .NET Framework. .NET Framework will ship with windows as usual.

[shrinidhi111]

Anyhow, our company has moved onto GoLang. It has an absolutely killer feature that creates low level native binaries across all platforms without any additional runtime needed. Plus the experience of adding modern concurrency to the application has been a breeze. It's the best of both worlds imo.

Although personally, I don't care, management was really not happy making customers install additional runtimes (and updates for these runtimes). Even bundled binaries are gigantic in .Net compared to the binaries that are created in GoLang. So far my Go experience has been amazing.

It's sad that older Windows operating systems (like Win 7) get more love outside MS.

Even Google apps works better in an outdated browser like IE than Microsoft's own webpages lol

[davidfowl]

@shrinidhi111 out of curiosity, what types of applications are you building? Command line tools?

[terrajobst]

@poke

we're trying really hard to avoid this.

The usual reasoning I hear behind this is that shipping it with the OS means that it is bound to the same update cycles as the operating system.

No, the update speed isn't the problem. We service .NET Core via Microsoft Update.

The problem is that as soon as you bundle a .NET version with the OS, which version are you bundling? Say in Windows 10 we bundled .NET Core 3.1. Now let's say we want to bundle .NET 6 in Windows 11. Does this mean upgrading from Windows 10 to 11 would result in losing .NET Core 3.1? Does Windows 11 come with both .NET Core 3.1 and .NET 6? The only sane answer to both questions is no. But unless .NET supports roll forward across major version you can't easily build an application now that works on Windows 10 and Windows 11. And as soon as we allow roll forward we're back to .NET Framework's insane in-place update compatibility bar because the developer is no longer in control on which runtime the application ends up running.

Having a runtime installed by default would really help the adoption of .NET (Core) in the desktop space.

We found the opposite to be true. .NET Framework versions are adopted very slowly due to the in-place update requirements and IT departments taking their time testing it. On the other hand, .NET Core is being adopted way faster by consumers.

[MichaeIDietrich]

It'll great if so though, many clients are unhappy with installing additional runtimes so we are forced to limit our development to whatever framework is most common

Consider doing a self-contained deployment. Also, .NET 6 comes with a much improved linker.

That's the way to go.

But unfortunately publishing a WPF application still does not support trimming, so even the most basic WPF application will be at least 150MB of data. That's really a shame. :/

[juwens]

@terrajobst this is very disappointing.
As a SW company, I need to explain to every customer, please install .Net, if you don’t want one or more 200MB LOB apps. Small Helper or Admin or CLI tool 200MB. Which would be 5MB or less in classic .Net Framework.
Either my app is self contained and will get no security updates for the framework from the OS.
Or I need to explain and discuss with every customer, why they should install .Net 5, later .Net 6 and in one year .Net 7 and so forth.

[terrajobst]

If you're building an enterprise app, the expectation is that you don't go self-contained but rather let your IT department roll out machine-wide .NET installations. In contrast to .NET Framework, these are fully side-by-side so you can have as many versions as you need to support your set of applications.

Self-contained is the preferred case for ISVs (such as TurboTax or Visual Studio). We know from experience that for that kind of apps depending on a machine-wide framework can be problematic. ISVs often have their own auto-updating service and by bundling .NET with their app they get to control their destiny to a 100%, something that a shared framework can't easily deliver on.

Or I need to explain and discuss with every customer, why they should install .Net 5, later .Net 6 and in one year .Net 7 and so forth.

Unless your target is some fairly old version of .NET Framework you need to bundle the .NET Framework installer with your app today or have that conversation with your customers. From my own experience as an ISV: bundling .NET with the OS doesn't remove that friction.

That said, I'm more than happy to jump on a call and go over the scenarios you're interested in to see how well (or not) .NET can help with those. If you're interested, please send mail to immol at microsoft dot com.

[juwens]

If you're building an enterprise app, the expectation is that you don't go self-contained but rather let your IT department roll out machine-wide .NET installations. In contrast to .NET Framework, these are fully side-by-side so you can have as many versions as you need to support your set of applications.

Self-contained is the preferred case for ISVs (such as TurboTax or Visual Studio). We know from experience that for that kind of apps depending on a machine-wide framework can be problematic. ISVs often have their own auto-updating service and by bundling .NET with their app they get to control their destiny to a 100%, something that a shared framework can't easily deliver on.

Or I need to explain and discuss with every customer, why they should install .Net 5, later .Net 6 and in one year .Net 7 and so forth.

Unless your target is some fairly old version of .NET Framework you need to bundle the .NET Framework installer with your app today or have that conversation with your customers. From my own experience as an ISV: bundling .NET with the OS doesn't remove that friction.

That said, I'm more than happy to jump on a call and go over the scenarios you're interested in to see how well (or not) .NET can help with those. If you're interested, please send mail to immol at microsoft dot com.

Thanks a lot for the answer and the invitation.
I will let your answer sink in and write to you later.

In generell, we are creating an App wich provides “self service” Installation of packaged company LOB apps/msix packages, installed with user rights, no elevated privileges. Roughly similar to an enterprise MS Store, but much! simpler and with customer specific features.
Also similar to the Visual Studio or Jetbrains Installer, but the installed LOB Apps are packaged DesktopBridge Apps installed for the user.
I thought packaged Apps is the way, MS is heading. I also like the the benefits which packaged Apps do provide.

The “Self Service LOB Install/Enterprise Store App” could theoretically install the necessary .Net Frameworks, but I guess this requires elevated privileges IIRC.

[An-nima]

My suggestion is to provide an interface by the official. When the detection program needs to use a certain .Net version, it will prompt to install .Net core like the previous prompt to install .Net framework. Users only need to click allow to install, which will save a lot of time and do not need to explain a lot to users.

[shrinidhi111]

@shrinidhi111 out of curiosity, what types of applications are you building? Command-line tools?

Initially ported our Windows services from .Net to GoLang. Now in the process of porting our server-side from Spring Boot to GoLang.

At the client end, we found that its much easier to create binaries for all Windows OS-Architecture combinations with very little effort. No runtime. No additional installations like the corresponding Windows updates (you'll be surprised how many of our customers still use Windows 7 which is not even updated. Sometimes a full day of our support team would be spent on ONE customer helping to install SP1, then install all the latest updates and finally install .Net to run the service.). The move to golang for Windows clients is almost night and day.

On the server-side there is cost benefits in terms of resources consumption (an idle JVM service takes RAM in GBs; at least an order of magnitude higher of that of golang ones). Plus there is speed benefits thanks to concurrency. Not that it was not possible in Java but its much easy in Go. Our latest load test showed a 10 times benefit with just a one to one port; no drastic change in algorithm or design. So we are confident in our choice.

Of course I hear lot of good stuff in .Net too on the server side but I do not have much experience at enterpise level. I would assume its resource consumption is like Spring given the runtime overhead needed.

[McoreD]

No. We don't have any plans to bundle .NET into the OS and we're trying really hard to avoid this.

Planning to avoid this? Why? Windows always bundled .NET and it would be shame not to have .NET 6 pre-installed. Why make it harder for users to access apps developed using .NET?

[McoreD]

@terrajobst what's the reasoning behind not bundling .NET with Windows?
What is going to happen when .NET Framework 4.8 (which is currently bundled with Windows 11) is depreciated? You will not have any .NET version bundled at all?

[terrajobst]

I've given that rationale here:

#6411 (comment)

[terrajobst]

What is going to happen when .NET Framework 4.8 (which is currently bundled with Windows 11) is depreciated? You will not have any .NET version bundled at all?

There are no plans to remove .NET Framework from Windows. Equally, we have no plans to bundle .NET Core with Windows. Above I explained what we expect customers to do instead.

The question is which version are we bundling with Windows? Bundling all versions clearly won't scale. If latest Windows only bundles latest .NET Core, then depending on this usually doesn't work super well because customers tend to want to work on older versions of Windows, so in the end you still need to bundle .NET with your app.

[McoreD]

I've given that rationale here:

#6411 (comment)

@terrajobst thanks for your response, and I did read that prior to asking my question. Unfortunately it did not explain the reason for not bundling .NET with Windows. Expection is one thing, but what is the reason? Surely it is not a technical limitation. The expectation can be avoided if .NET is pre-installed with Windows, that's why I am asking. If I need to rephrase, what's the reason for the expectation?

[McoreD]

@terrajobst okay this response answered my question as it explains the logic behind the reasoning. Thanks for that.

However, the counter-argument is that by bundling a version, as opposed to no version, will reduce the need to install the required .NET Framework for many customers. The exact percentage, I cannot tell, but it will follow the patterns in a normal distribution as you'd know.

If you are concerned about bundling will drive the wrong behaviour amongst the developers, then I understand. Most developers will choose to limit themselves to make their apps compatible the bundled version. To encourage all developers to focus on the latest .NET version, I get that this could be more strategic.

Thanks again for your response.

[terrajobst]

However, the counter-argument is that by bundling a version, as opposed to no version, will reduce the need to install the required .NET Framework for many customers. The exact percentage, I cannot tell, but it will follow the patterns in a normal distribution as you'd know.

Right, but how does this help your users or you? Since you don't know which version of .NET happens to be on a specific machine you'll still need to bundle the .NET installer.

The only reason .NET Framework apps tend to get away with not doing that is because .NET Framework versions only shipped every 2 to 3 years. On top of that, .NET Framework has an in-place compatibility bar which meant that we needed to make it safe to be rolled forward when a new version was shipped via Microsoft Update. Installing these new versions side by side was prohibitively expensive, due to size. This extremely high compatibility bar is also what made it very hard, and in some cases outright impossible, for us to innovate in the platform. With .NET Core, we had an explicit goal to make reasonable breaking changes practical without breaking applications built & tested for an earlier version.

Now .NET ships once a year; we see developers adopting newer versions of .NET much more quickly compared to .NET Framework. I really don't see how us bundling .NET with Windows would help with that at all. If anything, this would result in complicated matrixes which versions of Windows come with which version of .NET and how/when these are updated. The end result would still be that application developers would need to bundle .NET with their apps.

[Qiu233]

The team might need to make the logs clearer if users doesn't install the runtime. And there's should be an automatic downloading/installing procedure like .NET Framework does.

[reitowo]

If we need to self contained everything, what's difference between shitty electron that have tons of same binary on user's device? What's the point of a 'framework'?
I simply don't understand that bundling .NET in Windows OS is good for everyone, why are you trying so HARD to avoid it. It is good for microsoft to expand .NET community, good for users to run .NET applications without the cost to install another thing, good for developers to not teaching users install .NET or being forcecd to self-contain .NET and makes the application size explode to 100MB which as trash as electron.

[armour-sheila]

I can if I didn't achieve.

[xcaptain]

Most linux distros bundled a python runtime, a lot of programs use this pre-installed python and works well. I don't see any reason why windows and .net not follow this style, it's technically available.

[reitowo]

Is it so hard to write a localized version of the auto .NET downloader?

[martin-braun]

This is about .NET (5/6, etc), not .NET Framework. .NET Framework will ship with windows as usual.

This are messed up simply by renaming ".NET Core" to ".NET". No wonder people get confused.

[reitowo]

Everytime this thread pops up I just feel shame for Microsoft for letting go such advantage the .NET could provide to its community and Windows ecosystem. Even Linux is easier to use .NET

[martin-braun]

@cnSchwarzer Yes, today I ported a WPF .NET Core app to WPF .NET Framework, because we need to silently / remotely update the application without UAC prompt (user scope). Once .NET Core version support runs out, we can't update our application without interfering with a new Runtime, whereas with .NET Framework, we can simply let the Windows Update do its thing and raise our .NET Framework in our WPF application accordingly.

It's been years I'm confused about that, especially why WPF on .NET Core is even a thing for the very same reasons I stated above and also due to the fact, that WPF can run only on Windows anyways.

(Somebody will say that I can deploy the runtime on my own, I know I know, but why would I invest my time (and thus my money) into this, when it's so much easier with .NET Framework, what a joke.)

[suprak]

@martin-braun For similar reasons for our ClickOnce app, we created a simple NETFramework loader app that checks for the presence of the NET6 and then launches our main dotnet WPF app.

This way our development can leverage the lates NET advancements.

However, definitely unnecessary complexity.

[rizamarhaban]

We don't need .NET installed on Windows in the first place. You can publish .NET including all the runtime. Even better in .NET 8 later where we can use native AOT compilation. There is no reason for Microsoft to install .NET runtime on Windows 11. The existing .NET Framework is legacy for old apps. Only some apps sfill need old .NET Framework.

[reitowo]

We don't need .NET installed on Windows in the first place. You can publish .NET including all the runtime. Even better in .NET 8 later where we can use native AOT compilation. There is no reason for Microsoft to install .NET runtime on Windows 11. The existing .NET Framework is legacy for old apps. Only some apps sfill need old .NET Framework.

Like I mentioned before, why the user need to waste their disk space for tons of same copy of .NET runtime? Do you know that almost certain an serious app cannot strip assembly for size because so much things in dependency use reflection? Why let user complaints about the big size if we ship runtime with our application? Why make developers to develop their own silent .NET installer, introducing so much unnecessary complexity?

It is funny to ask, but does .NET team and Microsoft forget how to create a decent app for users?

Please do not make .NET the next LibCEF, thanks.

[rizamarhaban]

@cnSchwarzer I think we need separate runtime and the size is small especially when it's trimmed or later in .NET 8 can use AOT. Very small fingerprints for the sake of easy maintenance.

For me, it must have separate runtime for a good reason, that's versioning. And I'm able to upgrade and do changes without having conflicts with other applications. Just look at C++ libraries. You need to bring it all for every application. This is a good strategy for developing software as there is no dependency with the OS.

The size is not huge when it's trimmed or using AOT compilation later.

[reitowo]

@cnSchwarzer I think we need separate runtime and the size is small especially when it's trimmed or later in .NET 8 can use AOT. Very small fingerprints for the sake of easy maintenance.

For me, it must have separate runtime for a good reason, that's versioning. And I'm able to upgrade and do changes without having conflicts with other applications. Just look at C++ libraries. You need to bring it all for every application. This is a good strategy for developing software as there is no dependency with the OS.

The size is not huge when it's trimmed or using AOT compilation later.

Doesn't .NET runtime compatible across minor version numbers?

I know Windows is minimizing the system size, but doesn't it clear that "ship 1 .net runtime with system" is significantly better than "ship 100 .net runtime with app"?

Anyway, all the complaint about this is we want an silent and decent, prompt free .net runtime installation process, which significantly lower the user's interaction cost. If compatible .net runtime is installed on system, we can also save space for user.

About stripping symbols, many precompiled library and dependencies cannot be stripped because reflection is used in them, and will cause error at runtime.

Lets take WPF as an example, how do you even strip an WPF app?

I think libcef app is not that wise, and want to prevent my .net app becoming it.

[rizamarhaban]

@cnSchwarzer then I suggest to add the runtime using the setup installer. I did it easily using WiXtoolset. Just detect if there is .NET runtime exist, don't install it, if not exist then install it. Problem solved. But I prefer the runtime is on the app itself. Why must the OS handle it because of this. Is just doesn't make sense. The good thing as well is you can uninstall the runtime or replace with latest one if needed per app.

Example, my app disk size after publishing the WPF app is less than 80MB without a separate runtime installed. And 80MB includes the resources in the app. 80MB is considered small in today's world IMO. That's because so many DLL that is not part of .NET runtime was included. Which is DLLs for Windows in .NET. The runtime itself is considered small IMO. Especially libraries using netstandard 2.0 or 2.1 when trimmed also can be very small.

Anyway, this is my opinion and works fine with my work. I love this way because I no longer need to focus on the OS but rather the app itself which can be run anywhere, in any OS platform/version without having dependent on .NET runtime from the OS.

[Qiu233]

Everytime this thread pops up I just feel shame for Microsoft for letting go such advantage the .NET could provide to its community.

Agree. .NET installation on linux turns out to be easier than on Windows now, what a shame.

[McoreD]

When it comes to programming, nothing requested here or discussed here is impossible to implement.

Microsoft could, if wanted to, roll out the latest .NET version, and the last two versions of .NET for compatibility purposes through Windows. Windows Updates could show these as Optional Updates, which is another way to do it.

The decision to not do any of the above is a decision made by individuals, and not a programming limitations. We are not going to convince anyone here as they have already made up their mind.

[GF-Huang]

LOL, Micro$oft even lazy to pre-install VC++ redistributable in the operating system.