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

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:

@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 - https://github.com/dotnet/core-setup/pull/8509. It will also send folks to the page I mentioned above.

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.

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 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.

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 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.

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 https://github.com/dotnet/core-sdk/issues/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.)

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 https://github.com/dotnet/core-sdk/issues/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.

1. Visited https://dotnet.microsoft.com/download on this computer and downloaded the Download .NET Core Runtime for desktop apps and installed it
2. 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.