[release/3.1] Include .NET Core Runtime in WindowsDesktop bundle #8508
Conversation
|
What happens if the bundled .NET Core runtime is already installed?
|
|
What happens if the WindowsDesktop runtime is already installed (say, using the dotnet install script, not the installer), but the bundled .NET Core runtime is not installed yet ?
|
|
/cc @rladuca |
|
What are the implications (if any) of this with respect to building WindowsDesktop in the separate repo? Do we not build installers there? Does the runtime installer have to flow to the WindowsDesktop repo in some sort of loop? |
@dagood, am I correct in thinking that the the same core-setup build used to produce both WindowsDesktop and .NET Core installers previously, and now you are simply chaining two of those build artifacts together ? |
Yep, the way this works is that each MSI has its own identity and dependencies on each one are ref-counted. The .NET Core Runtime Bundle has one reference to it, and installing the .NET Core Desktop Bundle will add its own reference to those specific component MSIs. This does have the consequence that if you upgrade WindowsDekstop but not .NET Core Runtime, then you end up with both the old and new one installed SxS. (This is the same as having an old Runtime Bundle present and installing a new SDK Bundle.)
The dotnet install script, to my knowledge, always writes to some user-writable dir (a repo, user profile, ...) and never interacts with the global install. I don't think this exact situation can happen. But I think it's similar if someone has, say,
Yes, ref counting should sort this out fine in general.
That's right, I need to file an issue to reimplement this for 5.0+ where WindowsDesktop is split out. (EDIT: Oh, right, already did this: dotnet/windowsdesktop#20. 😄)
There must be a flow from Core-Setup => WindowsDesktop, but this shouldn't cause a loop. This dependency is already required for other reasons anyway, like making sure the reference closure is valid. |
This is the situation we'll be in if we port this to
|
|
Tactics approved |
Description
https://github.com/dotnet/core-setup/issues/8504: Includes the .NET Core Runtime MSIs inside the .NET Core Desktop Bundle (WindowsDesktop).
Customer Impact
The current state of 3.0+ is that you need to install both the .NET Core Runtime Bundle and the .NET Core Desktop Bundle in order to run a WinForms or WPF FDE/FDD app. This causes a lot of confusion, because:
These are solved by including .NET Core Runtime inside the .NET Core Desktop Bundle. The user still needs to select the correct architecture(s) to install, but this will be mitigated by creating an improved download page specific to the .NET Core Desktop Runtime Bundle. https://github.com/dotnet/core-setup/issues/7763 tracks also combining the architectures.
This becomes harder to hit because it won't be possible to run the .NET Core Desktop Bundle without also getting the .NET Core Runtime. However, the lack of feedback will still occur if the user tries to launch an FDE app without the prereq runtimes installed, so this is still an important issue.
Regression?
No.
Risk
Low. We have not fully tested and considered the effects of including the .NET Core Runtime with the .NET Core Desktop Bundle, however this is same approach as the SDK Bundle: the general principle is known and has worked for a long time. (Edit: The comments explore some interesting scenarios, and they don't raise any concerns.)
Tested by running
dotnet new winformsanddotnet new wpfFDE apps on a VM with only the .NET Core Desktop Bundle installed, and both worked./cc @KathleenDollard @rowanmiller @vatsan-madhavan @richlander