WPF application uses different versions of .NET runtimes

[duskembayev]

Description

I have WPF application with generated .runtimeconfig.json

{
  "runtimeOptions": {
    "tfm": "net5.0",
    "rollForward": "disable",
    "framework": {
      "name": "Microsoft.WindowsDesktop.App",
      "version": "5.0.6"
    }
  }
}

The application uses two different runtime versions at the same time. Looks like, Microsoft.NETCore.App framework ignores rollForward option.

Sample project: https://github.com/duskembayev/dotnet_runtime_issue_54669

Configuration

OS Name Microsoft Windows 10 Enterprise
Version 10.0.18363 Build 18363

dotnet --list-runtimes
Microsoft.AspNetCore.App 3.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.16 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 3.1.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.16 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.1.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 3.1.16 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 5.0.6 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 5.0.7 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other information

It works properly if I declare explicitly all frameworks in .runtimeconfig.json

{
  "runtimeOptions": {
    "tfm": "net5.0",
    "rollForward": "disable",
    "frameworks": [{
            "name": "Microsoft.NETCore.App",
            "version": "5.0.6"
        }, {
            "name": "Microsoft.WindowsDesktop.App",
            "version": "5.0.6"
    }]
  }
}

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

I have WPF application with generated .runtimeconfig.json

{
  "runtimeOptions": {
    "tfm": "net5.0",
    "rollForward": "disable",
    "framework": {
      "name": "Microsoft.WindowsDesktop.App",
      "version": "5.0.6"
    }
  }
}

The application uses two different runtime versions at the same time. Looks like, Microsoft.NETCore.App framework ignores rollForward option.

Sample project: https://github.com/duskembayev/dotnet_runtime_issue_54669

Configuration

OS Name Microsoft Windows 10 Enterprise
Version 10.0.18363 Build 18363

dotnet --list-runtimes
Microsoft.AspNetCore.App 3.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.16 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 3.1.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.16 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.1.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 3.1.16 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 5.0.6 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 5.0.7 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other information

It works properly if I declare explicitly all frameworks in .runtimeconfig.json

{
  "runtimeOptions": {
    "tfm": "net5.0",
    "rollForward": "disable",
    "frameworks": [{
            "name": "Microsoft.NETCore.App",
            "version": "5.0.6"
        }, {
            "name": "Microsoft.WindowsDesktop.App",
            "version": "5.0.6"
    }]
  }
}

Author:	duskembayev
Assignees:	-
Labels:	area-Host, untriaged
Milestone:	-

[vitek-karas]

The runtime config of the Microsoft.WindowsDesktop.App looks like this:

{
  "runtimeOptions": {
    "tfm": "net5.0",
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "5.0.6",
      "rollForward": "LatestPatch"
    }
  }
}

So it explicitly allows latest patch. The rollfoward setting is not inherited, each framework reference defines it anew. I understand that in this specific case it probably doesn't do what you want. At the same time, declaring all framework references explicitly in this case doesn't seem like a terrible solution.

The framework resolution algorithm is described here: https://github.com/dotnet/runtime/blob/main/docs/design/features/framework-version-resolution.md. Although this particular case is probably not covered there.

[duskembayev]

Thanks, @vitek-karas.

Currently, I'm looking for the right way to generate .runtimeconfig.json with a customized frameworks section containing all required records.
I already tried to declare runtimeconfig.template.json, but it is not applicable to frameworks section.

Could you, please, suggest a solution?

[vitek-karas]

I'm no aware of any which is directly built into the SDK. You can create a post-build step which overwrites the file.

Just curious: Why is it important to you to disable roll-forward completely?

[duskembayev]

You can create a post-build step which overwrites the file.

Yes, I know, but this way doesn't look right. Maybe in future versions, there will be better ways to do such customizations.

Why is it important to you to disable roll-forward completely?

The sample above is just for demonstration. Actually, real application delivered to end-user with customized runtime and CLR hosting. That's why at the current stage of development we want to ensure that the exact version of the runtime is used.

Anyway, current behavior looks very strange. I'm sure that Microsoft.WindowsDesktop.App uses the internals of Microsoft.NETCore.App. As a consequence, Microsoft.NETCore.App should support backward compatibility for patches of internal features.
My opinion: CLR should guarantee the same version for all apps of runtime.

Thanks!

[vitek-karas]

Anyway, current behavior looks very strange. I'm sure that Microsoft.WindowsDesktop.App uses the internals of Microsoft.NETCore.App. As a consequence, Microsoft.NETCore.App should support backward compatibility for patches of internal features.

Microsoft.NETCore.App is backward compatible, that's why it's OK to run 5.0.7 NetCore with 5.0.6 WindowsDesktop.

The reason for allowing patch roll-forward are security patches - let's say we need to patch the NetCore.App, if the versions were 100% rigid, we would also have to release a new version of WindowsDesktop, just to allow the higher version of NetCore.App.

Actually, real application delivered to end-user with customized runtime and CLR hosting. That's why at the current stage of development we want to ensure that the exact version of the runtime is used.

So you install your customized runtime into a global location? (like Program Files) If you're not, then I don't see the need to freeze the versions since you would have full control over the install location (not allowing any other versions there).

[duskembayev]

So you install your customized runtime into a global location? (like Program Files) If you're not, then I don't see the need to freeze the versions since you would have full control over the install location (not allowing any other versions there).

We install runtime into a custom (not global) location. But it can contain multiple versions of runtime (i.e. 5.0.6, 5.0.7, 6.0.0, etc.) at the same time.

As I said before, we implemented some CLR customizations (such as custom location, sandboxing, custom clr hosting, plugin system). If you are interested in our cases - I can provide more details privately (email or call). We will be happy to discuss the implemented solutions.