MU brings newer version of Microsoft.AspNetCore.App without corresponding version of Microsoft.NETCore.App

[satishviswanathan]

I ran into an issue that dotnet version "8.0.5" is missing. My application is targeting sdk "version": "8.0.204" which uses the runtime version 8.0.4. Through a windows security patch we got Microsoft.AspNetCore.App 8.0.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] pushed into the developer machine. Since then I'm getting this error at the time of application start up.

One observation was this is happening because we have the following framework reference through some common libraries that we are using.

<FrameworkReference Include="Microsoft.AspNetCore.App" />

I was expecting the version specified in the runtimeconfig.template file would be honored but that doesn't seems to be happening. Not sure if this is an issue or something I'm missing here. Any help on this is appreciated.

OS: Windows

SDK and Runtime list

runtimeconfig.template.json

{
  "runtimeOptions": {
       "tfm": "net8.0",
        "rollForward": "Disable",
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "8.0.4"
    },
    "configProperties": {
      "System.GC.Concurrent": false,
      "System.GC.Server": true
    }
  }
}

global.json

{
  "sdk": {
  "version": "8.0.204"
  }
}

Error

Architecture: x64 Framework: 'Microsoft.NETCore.App', version '8.0.5' (x64) .NET location: C:\Program Files\dotnet\

The following frameworks were found: 2.1.30 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] 6.0.30 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] 7.0.2 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] 7.0.3 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] 7.0.18 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] 8.0.1 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] 8.0.3 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] 8.0.4 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

Learn more: https://aka.ms/dotnet/app-launch-failed

To install missing framework, download: https://aka.ms/dotnet-core-applaunch?framework=Microsoft.NETCore.App&framework_version=8.0.5&arch=x64&rid=win-x64&os=win10

[dotnet-policy-service[bot]]

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

[agocke]

It looks like you have the 8.0.5 version of Aspnetcore, but the 8.0.4 version of the runtime (Microsoft.NETCore.App). Since Aspnetcore depends on Microsoft.NETCore.App, that can't work.

This seems like some sort of installer issue -- it doesn't seem like it should be possible to get one without the other.

[satishviswanathan]

@agocke - Thank you for your response.

In my runtime list I do have Microsoft.NETCore.App and Aspnetcore runtime 8.0.4 and in the runtimeconfig I do have mentioned the runtime version as 8.0.4, this was working until Aspnetcore 8.0.5 got pushed to my machine.

[agocke]

Right -- the problem is that Microsoft.AspNetCore.App 8.0.5, which has an implicit dependency on Microsoft.NetCore.App 8.0.5. When you got Microsoft.AspNetCore.App 8.0.5 you (for some reason) didn't get Microsoft.NetCore.App 8.0.5, which is what caused the break.

Unfortunately I don't know how this could happen -- I don't really understand the behavior of Windows Update with respect to the .NET Core components.

@joeloff Might understand how the different components are related.

[satishviswanathan]

Understood. Due to some reason windows update didn't get Microsoft.NetCore.App 8.0.5.

But since I have mentioned the run time as 8.0.4 in runtimeconfig.template.json and was expecting that runtime version to be picked. I thought the problem might be with the runtime.template.json because the version mentioned in this file is not what is being picked. Not sure if I'm missing anything here.

This issue happens only if I have the framework reference as shown below. If this reference is removed then the app picks 8.0.4. That is what I've observed with a simple test app that I had created.

[agocke]

But since I have mentioned the run time as 8.0.4 in runtimeconfig.template.json and was expecting that runtime version to be picked.

That runtime is being picked. But that setting doesn't affect ASP.NET <FrameworkReference Include="Microsoft.AspNetCore.App" />. I expect that would pick the newest version available, regardless of what runtime you're running on.

[satishviswanathan]

@agocke got you. What's your recommendation to address this issue ? This has been a problem in our developer environment which get's these updates pushed to their machine and we are each time forced to upgrade.

[agocke]

I'm not an expert on ASP.NET, but I think the ideal state would be using the ASP.NET SDK, rather than the basic NET SDK. So, removing the framework reference and setting <Project Sdk="Microsoft.NET.Sdk.Web"> for your project. Absent that, you could manipulate the runtimeconfig.json directly. So, where you currently have

    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "8.0.4"
    },

you would have

    "frameworks": [
      {
        "name": "Microsoft.NETCore.App",
        "version": "8.0.4"
      },
      {
        "name": "Microsoft.AspNetCore.App",
        "version": "8.0.4"
      }
    ],

I don't recommend doing the latter long-term -- manipulating the runtimeconfig.json manually can get you into an unsupported state if it's not something the SDK would emit by itself, but it might unblock you while you rebuild your app with an ASP.NET target.

[joeloff]

So this happens because MU triggers off the individual installation bundles (EXEs). The ASP.NET bundle only carries ASP.NET, it does not carry the NET runtime/host like Desktop does.

If you have both the standalone .NET Runtime and ASP.NET Core runtimes installed, MU will trigger for both. But if you acquired .NET through VS and then installed the standalone ASP.NET runtime, MU will update ASP.NET, but not the runtime because that's managed by VS and you can get out sync.

The separate ASP.NET runtime goes back to 2.0 (when it was called the ASP.NET Core Package Store). There were very specific use cases for the separate runtimes and most of this was around hosting providers and so that people could incrementally add additional runtimes. It was never updated to be on par with other frameworks like Desktop to carry the full runtime.

@wtgodbe it might be worth looking into making ASP.NET consistent and similar to Desktop.