32 Bit Runtime Discovery for Desktop Apps

[RickStrahl]

Steps to reproduce

I'm unable to get a WPF application that targets x-86 to launch in shared runtime mode even though the appropriate runtime is installed:

As you can see the 32 bit (and 64 bit runtimes are installed). If I target 64 bit the app works self-contained.

Expected behavior

Runtime loader should be able to figure out the location of the 32 bit runtime.

Actual behavior

Application starts and gives an error that the runtime isn't found. Additionally the error message makes no mention of 32bit/x86 which makes this even more confusing as you can't tell what it's actually looking for.

Environment data

Windows 10
.NET Core 3.0 Preview 5 (latest bits installed today)
WPF application target

Here's the relevant project file info:

<PropertyGroup>
    <OutputType>WinExe</OutputType>
    <!--<TargetFramework>net462</TargetFramework>-->
    <TargetFrameworks>net462;netcoreapp3.0</TargetFrameworks>
    <Version>1.16.18</Version>
    <AssemblyName>MarkdownMonster</AssemblyName>
    <UseWPF>true</UseWPF>
    <StartupObject>StartUp</StartupObject>
...
    <ApplicationManifest>app.manifest</ApplicationManifest>
    <TieredCompilation>true</TieredCompilation>
    <RuntimeIdentifier>win-x86</RuntimeIdentifier>
    <SelfContained>false</SelfContained>
</PropertyGroup>

32 bit app works in self-contained mode

Additional notes

I guess the question is how is this supposed to work. I assume this is broken but previously I already discovered that pathing seems to override which SDK and runtimes are used and install order can mess this all up.

I hope that this is broken currently and there will be a better story for probing for runtimes but I can't find any definite information that describes the process.

I would expect the runtime loader to be able to tell that it's supposed to load a 32 bit runtime and probe in the appropriate runtime install folder for the required runtime.

[dasMulli]

What did you use to install the x86 version? looks like the desktop UI shared framework isn't part of the ".NET Core Runtime" installer, just the x86 SDK..

You can check in C:\Program Files (x86)\dotnet\shared if there is a Microsoft.WindowsDesktop.App folder.

@nguerrera Are there runtime installers for the DesktopUI sharedFx installers? The download page has .net core runtime and separate asp.net core downloads (which have asp.net core sharedfx) but no DesktopUI. Hosting bundle doesn't have it either.

[nguerrera]

^ @dagood @leecow is there a runtime installer bundle with windows desktop runtime available yet? If not, is there already an issue tracking it? I know we talked about this before, but I can't find a tracking item.

[dagood]

WindowsDesktop shared framework MSI installers exist (e.g. https://dotnetcli.blob.core.windows.net/dotnet/Runtime/master/windowsdesktop-runtime-latest-win-x64.msi, https://dotnetcli.blob.core.windows.net/dotnet/Runtime/master/windowsdesktop-runtime-latest-win-x86.msi), but not bundles.

I think bundles have come up for the WindowsDesktop targeting pack (and maybe runtime pack) but not the shared framework, filed https://github.com/dotnet/core-setup/issues/6384.

As for this issue, closing as by design for now: the .NET Core Runtime shared framework bundle installer is not intended to carry WindowsDesktop.

[RickStrahl]

Yeah I used the standard runtimes, but wasn't even clear that a special runtime is required in order to provide the desktop execution. What is so special about that that it requires a separate runtime install given that all the Windows/Desktop features come as part of a Nuget package?

Frankly all this talk of having a server runtime, a desktop runtime, and an AspNet runtime, and and SDK download that may or may not have all those runtimes - it's bloody confusing.

At minimum each of those installers need to have their own dedicated download page so that you can send an end user to grab the appropriate version without getting mired in understanding all this version madness.

[dagood]

The big issue here is that we haven't produced a WindowsDesktop shared framework installer yet. (https://github.com/dotnet/core-setup/issues/6384) Therefore there's no info about it on the download page at all, and everyone has to make their best guess. It's absolutely not intuitive how to acquire everything right now.

(I may have muddied the waters by mentioning the MSI. You can technically install the WindowsDesktop shared framework using it, but it's missing features that a bundle installer (EXE) has and isn't suitable to put on download pages.)

At minimum each of those installers need to have their own dedicated download page so that you can send an end user to grab the appropriate version without getting mired in understanding all this version madness.

dotnet/core#2618 is very related to this. I agree it seems pretty absurd to point an end user at e.g. the table at https://dotnet.microsoft.com/download/dotnet-core/3.0.

What is so special about that that it requires a separate runtime install given that all the Windows/Desktop features come as part of a Nuget package?

I'm not following the connection between NuGet packages and the shared frameworks.

I'd say the WindowsDesktop shared framework is being treated equally specially as the ASP.NET Core one: to some degree, the shared frameworks installers need to be split up so you don't have to install way more than you need on a machine. A web server doesn't need WindowsDesktop; a WinForms or WPF app has no need for ASP.NET Core. (Modulo edge cases.)

---

I took my cue from nguerrera to look at the installers, but I see a Host feature request here that seems reasonable to me (not knowing a lot about the host). Reopening to track answering if this is a reasonable thing to add:

[The It was not possible to find any compatible framework version] error message makes no mention of 32bit/x86 which makes this even more confusing as you can't tell what it's actually looking for.

@vitek-karas, is it reasonable to add bitness to this error message?

[vitek-karas]

I think it's very reasonable. We need this specific error message to be as actionable as possible. The length doesn't really matter.
I filed dotnet/core-setup#6396 to track the changes to the host.

[RickStrahl]

Fair enough about the runtimes.

I wasn't taking into account that you actually have to have a large runtime installed to provide the Windows compatibility layer. I naively assumed that the <PackageReference Include="Microsoft.Windows.Compatibility" Version="2.0.1" /> provides all that but I suppose there must be a lot more to what makes up the runtime otherwise that thing would be massive. So what is actually in that and shouldn't that just be part of the Desktop runtime?

As far as distributions go, I think the key is to have easy download links to these Runtimes so that they are easy to link to from product download pages and perhaps also regularily released Chocolatey (or some other package manager) packages would greatly help to ease getting these packages installed as easily as possible or as a remote dependency for an application (ie. Choco or OneGet for example).

[dagood]

I see, yeah, the WindowsDesktop shared framework actually does contain a subset of that compat pack. 😄 The bits that WinForms and WPF need to run are selectively included in windowsdesktop.depproj#L10-L24.

According to some docs I found just now, it seems you shouldn't normally need to reference the compat pack--it's available to help port old apps without changing code:

https://docs.microsoft.com/en-us/dotnet/core/porting/windows-compat-pack
https://docs.microsoft.com/en-us/dotnet/core/porting/winforms
https://docs.microsoft.com/en-us/dotnet/core/porting/wpf

I encourage you to comment on dotnet/core#2618 (or related issues) if you have a scenario requiring an end-user-friendly landing page that isn't covered there. I'm not particularly tapped into that, and the right people are on those threads. An issue, I think, with pointing an end user at a landing page is that it isn't obvious how they will get security updates later.

Chocolatey packages for .NET Core are maintained by the community, at https://github.com/dotnetcore-chocolatey/dotnetcore-chocolateypackages.

(Closing because the error message improvement is tracked at https://github.com/dotnet/core-setup/issues/6396.)