.NET Core runtime for Desktop does not include the actual runtime and it doesn't block or prompt for it

[Symbai]

1. Created a plain .NET Core 3.0 WPF project
2. Rebuild in release mode
3. Copied the files in the release folder to a new computer which is missing .NET Core at all
   
4. Visited https://dotnet.microsoft.com/download on this computer and downloaded the Download .NET Core Runtime for desktop apps and installed it
5. Tried to start the program, nothing happens.

The event viewer says:

Description: A .NET Core application failed.
Application: WpfApp12.exe
Path: C:\Users\TestAccount\Desktop\WpfApp12.exe
Message: A fatal error occurred. The required library hostfxr.dll could not be found.
If this is a self-contained application, that library should exist in [C:\Users\TestAccount\Desktop\].
If this is a framework-dependent application, install the runtime in the global location [C:\Program Files\dotnet] or use the DOTNET_ROOT environment variable to specify the runtime location or register the runtime location in [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x64\InstallLocation].

//edit: dotnet publish creates >290 files even when not self contained with an overall size of 150mb. My thought was that installing the runtime would install these >290 files and avoid having me to ship a 150mb application. Similar to .NET Framework. If that's not the case then: What exactly is the runtime installer for? And whats the purpose of self-contained when even the not self-contained application would force me to ship >290 files and >150mb?

[danmoseley]

Does C:\Program Files\dotnet\host\fxr\3.0.0\hostfxr.dll exist?

[dagood]

4. Visited https://dotnet.microsoft.com/download on this computer and downloaded the Download .NET Core Runtime for desktop apps and installed it
5. Tried to start the program, nothing happens.

Did you also install the .NET Core Runtime? Missing it would explain hostfxr not existing and nothing happening. This message on the Desktop Runtime download page is meant to point to it:

https://github.com/dotnet/core-setup/issues/8363 is an earlier issue about this.

We also have https://github.com/dotnet/core-setup/issues/8222 tracking the poor experience (nothing happening!) when hitting this situation.

//edit: dotnet publish creates >290 files even when not self contained with an overall size of 150mb.

I'm not able to repro this, after dotnet new wpf dotnet publish I only get:

wpf-default\bin\Debug\netcoreapp3.0\publish
wpf-default\bin\Debug\netcoreapp3.0\wpf-default.deps.json
wpf-default\bin\Debug\netcoreapp3.0\wpf-default.dll
wpf-default\bin\Debug\netcoreapp3.0\wpf-default.exe
wpf-default\bin\Debug\netcoreapp3.0\wpf-default.pdb
wpf-default\bin\Debug\netcoreapp3.0\wpf-default.runtimeconfig.dev.json
wpf-default\bin\Debug\netcoreapp3.0\wpf-default.runtimeconfig.json
wpf-default\bin\Debug\netcoreapp3.0\publish\wpf-default.deps.json
wpf-default\bin\Debug\netcoreapp3.0\publish\wpf-default.dll
wpf-default\bin\Debug\netcoreapp3.0\publish\wpf-default.exe
wpf-default\bin\Debug\netcoreapp3.0\publish\wpf-default.pdb
wpf-default\bin\Debug\netcoreapp3.0\publish\wpf-default.runtimeconfig.json

Are you sure you didn't specify a runtime, like dotnet publish -r win-x64? That generates a self-contained app, where the large number of files is expected.

[Symbai]

@dagood Thanks this explains the issue, although the notice is not visible for me (might be browser setting, who knows). Sadly the choice of two installers wasn't a good idea. It means there are two dependencies now? Why? Why can't Desktop Runtime contain the .NET Core Runtime or vice versa (for Windows only)? Having two installers causes a lot of support issues for developers dealing with inquiries why the app doesn't start. It makes things more complicated than it should be.

The windows runtime installer should contain everything needed in order to run a windows .NET Core app whether its a console or WPF / Winforms app. Which strong argument exist that it has to be separated? I could fairly accept to have a .NET Core runtime standalone but the runtime for Desktop Apps alias WPF / Winforms should really contain everything it needs in order to run WPF / Winforms.

Didn't know specifying a runtime generates a self contained app thought it must use -self-contained parameter but this is likely documented as well and I just missed that. I guess this part can be ignored then.

[dagood]

Thanks this explains the issue, although the notice is not visible for me (might be browser setting, who knows).

This is a significant problem, we're relying on this message while the installer's in its current state. 😕 To be clear, when you go to https://dotnet.microsoft.com/download/thank-you/dotnet-runtime-3.0.0-windows-x64-desktop-runtime-installer (and cancel the download), you don't see the box above If your download doesn't start after 30 seconds[...]?

/cc @leecow

Sadly the choice of two installers wasn't a good idea.

It wasn't so much a choice. I wholeheartedly agree we aren't in an ideal state. I had time to implement the current installer, such as it is, but didn't have time to implement an installer that bundled everything together. (It requires significantly more infrastructure work.) We have some larger installer plans that will hopefully end up improving this in 3.1, see dotnet/installer#5019.

Didn't know specifying a runtime generates a self contained app thought it must use -self-contained parameter but this is likely documented as well and I just missed that. I guess this part can be ignored then.

I think the evolution of these SDK args over time may be why it's somewhat confusing. https://docs.microsoft.com/en-us/dotnet/core/deploying/deploy-with-cli has some details on the CLI args and which modes you end up with. Skimming through, I don't see detail on what happens when --self-contained isn't specified at all, but hopefully that page is still useful.

[danmoseley]

Did you also install the .NET Core Runtime? Missing it would explain hostfxr not existing and nothing happening. This message on the Desktop Runtime download page is meant to point to it:

@dagood I was confused by this also -- I read the download page carefully, but the message you mention is on the page that appears while the download occurs, and it's done so quickly that I was already not reading the web page at that point. Maybe it could go onto https://dotnet.microsoft.com/download as well. Or better still, the installer would block installation if its dependency was not present. (As alternatives to what you mention, having a combined installer)

[dagood]

I agree, typically I close download pages the instant my download starts. I'm not familiar with the reasons behind putting critical info on that page. (It's a pattern: we describe how to install the Linux binaries/tarball on the "thank you" page as well.)

@leecow maybe you have some insight?

[danmoseley]

It's even more confusing because these two look like equivalent things, but if I understand correctly, one of them has the core runtime and the other does not:

[dagood]

Good point, that's true, and even further, the first one also has x86/x64 bundled together, but the second is only x64.

[leecow]

@rowanmiller to help sort out how to make this more clear on the site.

[rowanmiller]

@dagood it sounded like you were able to reproduce the message not showing up on the "thanks for downloading page". Is that correct? If so, can you share details. It should show up for everyone.

I don't think the main download page is the right place to surface this, for two reasons:

1. In general, people don't read stuff here. They scan the links and make a quick decision. We've had much better success moving compat messages etc. to the "thanks for downloading" pages.
2. Throughout the site we avoid communicating extra complexity until a person has opted into a product/feature/download/etc. that requires the complexity. Adding more info to the main downloads page makes the decision harder for everyone, not just the smaller set of folks that want the desktop runtime.

[Symbai]

@rowanmiller The big mistake was made by having ONE page for developers + server admins + desktop users. It was okay when .NET Core was mainly used by developers and server admins and I can understand when the time was too short to make bigger changes to this page but now with Desktop devs + users it has been opened to the wide community.

On top of that unlike Framework the .NET Core Runtime can only be downloaded there. It would be much better to have a separate page for end users with three single and easy options to choose from:

Windows Runtime x64 / x86
Mac Runtime x64 / x86
Linux Runtime x64 / x86

And the Windows installer installs everything that is required to run any .NET Core app on Windows. Because you are right, the complexity becomes an issue. SDKs / Runtimes / Servers / Desktop / Windows / Linux / Mac. Developers might fight through this but for end users it won't be clear and I agree with dagood once a download started you are going to close the page if you are consumer and just want to get things to run.

I think for developers this isn't a big issue but I really fear to tell customers to go to that page and download runtimes because I dont think they will download and install the right ones, especially when its even more than one.

[dagood]

it sounded like you were able to reproduce the message not showing up on the "thanks for downloading page". Is that correct? If so, can you share details. It should show up for everyone.

No, I don't think anyone had that problem in the end, I think we're just not accustomed to paying attention to "thank you" pages.

(By the way, I filed dotnet/installer#5019 to track this scenario in the fancy new installer I mentioned, and filed https://github.com/dotnet/core-setup/issues/8379 for @danmosemsft's idea of having the installer detect its dependency as a mitigation.)

I do think it makes sense to consider as another mitigation a page/set of pages dedicated to WPF/WinForms app users. Seems like a reasonable way to deliver more info but without adding it to any main pages. (I'm not too familiar with the constraints of the site design, however.)

[rowanmiller]

Re-reading this now, based on an email thread, I originally missed what I think was being proposed (or at least one of the ideas).

I don't think we should add more complexity to the top level downloads page, but introducing a new page that is opened when you click the Download .NET Core Runtime for desktop apps does seem like a good idea. It's very much inline with the design principles of the site, where we introduce/explain complexity at the point it becomes necessary. That keeps the top level decision between Server/Desktop as simple as possible, and introduce the complexity of desktop to users that go down that path.

Are we all agreed that this is a good path to go down? cc @KathleenDollard for her input.

[KathleenDollard]

@Symbai Thank you for your input on this. We are just getting our heads around how people want to deploy their desktop applications. And as mentioned, we are in a broader process with the installers.

@dagood can you confirm that there is non-trivial effort in creating a combined runtime/desktop single install that would be hard to accomplish for 3.1.

I propose the following, on Windows only:

• Main page an end user friendly like @rowanmiller proposes.
• Link to a very end-user friendly page - that can also be linked to directly by authors that want to do that.
• That page have a step wise process:

1. Download runtime
2. Install runtime
3. Download desktop
4. Install desktop

If you'd like to test your installation - use dotnet --list-runtimes at a command prompt.

[Symbai]

While I prefer having a combined installer PLUS a user friendly page for end users with a perma link devs can link to, I also do like @KathleenDollard suggestion as an overall improvement. With a combined installer the step wise process would become just 2 steps instead of 4. Not only devs but also end users would appreciate a combined installer, it will be more accepted than having to install multiple things. I think we all would agree with this.

Thanks for taking care of my feedback.

[dagood]

can you confirm that there is non-trivial effort in creating a combined runtime/desktop single install that would be hard to accomplish for 3.1.

Yeah, the biggest issue is that the x86 and x64 installers are built in parallel on different machines, so at minimum there's build infra reorganization to do. To keep each issue focused I'll go into more detail on https://github.com/dotnet/core-setup/issues/7763.

[dagood]

can you confirm that there is non-trivial effort in creating a combined runtime/desktop single install that would be hard to accomplish for 3.1.

I realized that while the x86/x64 combination is difficult, we can make significant incremental progress by still producing separate x64 and x86 WindowsDesktop bundles, but having them include the .NET Core Runtime. This is significantly simpler to implement. I've filed https://github.com/dotnet/core-setup/issues/8504 for this specifically.

[rowanmiller]

FYI updates to the website are now live. We've simplified back to a single "Run apps" button on the main download page. This button takes you to a new runtime page that does a better job of differentiating desktop/server apps and has more info to help folks get the right stuff for desktop.

[Symbai]

Wow, that looks amazing! This is so much easier for non-developers. Just a small suggestion, I would make the Step 1 and Step 2 text only bold. Otherwise nice job!

[rowanmiller]

@Symbai if you want to a place to send end users of your application, then we also added https://dotnet.microsoft.com/download/dotnet-core/3.0/runtime/desktop, which is trimmed down to just the desktop runtime info.

There is a separate change underway to have a prompt to download the correct runtime built into .NET Core itself - dotnet/core-setup#8509. It will also send folks to the page I mentioned above.

[dagood]

Closing: we've made changes in various places to improve this scenario:

• Website is changed for 3.0+ to guide users through the process better.
• The .NET Core Runtime installer will be bundled with the WindowsDesktop installer for 3.1.
• The host in 3.1 won't be silent when someone missing prereqs tries to launch an FDE GUI app.

There is an improvement on the setup side that will happen later: combining the x86 and x64 runtimes into one installer to relieve FDE app users of that choice. I opened dotnet/windowsdesktop#136 to track that on the new repo, where 5.0+ is being developed. (I linked dotnet/installer#5019 earlier as the issue for this work, but it turns out we aren't going that way. Details inside.)

Please let me know if I'm missing some other pieces that still need to be tracked. 🙂

[crezyoz]

Wow.. As a long time WPF coder with Frameworks, my foray into .net core has stumbled on this publish install mess. How could MS not get this simple thing right at the start? In this thread I see a lot of excuses. Seriously pathetic folks.