So because you can have mutiple versions installed, or you can package it with an app , then the updates can be more rapid.
The problem with .Net framework is that everything, including system services rely on it - that means it needs years of testing and can't have any breaking changes. Basically they decided that packaging .net as part of windows was a mistake.
While .NET Framework updates annoyingly force every app to use it, I expect .NET Core to make it super difficult to secure apps that decided to hardcode some specific ancient release of it and allow no way to override it.
The mistake to include it in Windows was partly why more versions weren't made (because then they'd have to be serviced for the length of a Windows version's service lifetime; because then they'd contribute way more to Windows bloat).
"Just recompile with the new version!" I hear the cries already, said by people that have never had to support literally a thousand applications in a government data centre, half of which were built years ago by a vendor that is long since bankrupt.
If you have thousand apps, you probably also have a CI/CD system and you can gain fine grained control on your runtime management needs with .net build/publish.
MS does quite a few things poorly but they have done a solid job of operating in large enterprises.
Or more realistically, dozens of CI/CD systems, covering less than a third of the applications.
The problem is if developers are publishing self-contained apps with .NET Core, IT staff will be up a creek on vulnerability mitigation. While being able to pin specific .NET Core versions is nice for developers, being able to require the most current .NET Core version be used is important for IT staff who have to support these applications.
https://docs.microsoft.com/en-us/dotnet/core/deploying/#publ...