@mrlife thanks for contacting us.

Is this a Blazor Server application?

@javiercn Yes, it's Blazor Server.

@mrlife is it a self-contained deployment?

@mrlife I think you might have a mismatch on the dependencies. I'm not sure how you are doing the deployment, but I would suggest ensuring that the folder you are deploying the files to is clean as well as that you do a clean publish.

Hi @mrlife. We have added the "Needs: Author Feedback" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

@javiercn I believe it's not self-contained, since I run this command, which doesn't have -r`:

dotnet publish -p:PublishProfile=my-profile

and my-profile.pubxml contains:

<SelfContained>false</SelfContained>

I think you might have a mismatch on the dependencies.

Would installing a new version of ASP.NET Core really have an effect on an existing app that doesn't use the new version and wasn't changed at all?

@mrlife did you re-publish the app or was the only thing that you did install the new runtime and restart the service.

Hi @mrlife. We have added the "Needs: Author Feedback" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

@javiercn I didn't republish the app or restart the service, only installed the 6.0.5 update. Do we need to restart all apps after installing an update?

@mrlife I don't believe so, but I can't tell what happened here right away.

I'll let some other folks chime in.

I'm untagging Blazor since I don't think this is a Blazor specific behavior.

@dotnet/aspnet-build @Pilchie can you route this to the right place?

From what I understand, installing 6.0.5 causes some already running apps to fail.

@mrlife it looks like you are using the 3.1.405 SDK, and have the 6.0.5 Asp.Net runtime installed - what is the TargetFramework of your app? Can you try installing the latest 6.0 SDK and using that to run your app? The 3.1.405 SDK you're using doesn't know anything about 6.0 bits.

@wtgodbe I have the latest SDK on my development machine. The issue template I guess is a little unclear to me then; it just says .NET version, so I put in the dotnet --version from the host server, which doesn't have any development activity, but is where the issue occurs.

Could you share your app with us so we can try to get a repro? The error message you showed typically happens when your project file doesn't have its References set up correctly, but just updating from 6.0.4 to 6.0.5 shouldn't break a previously-working app in that way.

@wtgodbe I can share some redacted code, but I can't provide the app itself. If there's any specific code you'd like, please let me know.

@mrlife just the .csproj should be sufficient, and if there is a global.json file I'd like to see that as well

Sorry, should have said all .csproj files in the solution, and note which one you're actually running when you see the failure

There's only one project in the solution, so no worries there. Here it is:

<Project Sdk="Microsoft.NET.Sdk.Web">
    <PropertyGroup>
        <TargetFramework>net6.0</TargetFramework>
        <ImplicitUsings>enable</ImplicitUsings>
        <DefaultAppHostRuntimeIdentifier>win-x64</DefaultAppHostRuntimeIdentifier>
        <RuntimeIdentifiers>win-x64;osx-x64</RuntimeIdentifiers>
        <IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled>
    </PropertyGroup>

    <ItemGroup>
        <PackageReference Include="Microsoft.AspNetCore.Authorization" Version="6.0.5" />
        <PackageReference Include="Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore" Version="6.0.5" />
        <PackageReference Include="Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation" Version="6.0.5" />
        <PackageReference Include="Microsoft.AspNetCore.SignalR.Client" Version="6.0.5" />
        <PackageReference Include="Microsoft.EntityFrameworkCore" Version="6.0.5" />
        <PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="6.0.5">
            <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
            <PrivateAssets>all</PrivateAssets>
        </PackageReference>
        <PackageReference Include="Microsoft.EntityFrameworkCore.Relational" Version="6.0.5" />
        <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="6.0.5" />
        <PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="6.0.5">
            <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
            <PrivateAssets>all</PrivateAssets>
        </PackageReference>
        <PackageReference Include="Microsoft.Extensions.Hosting.WindowsServices" Version="6.0.0" />
        <PackageReference Include="Microsoft.Extensions.Logging.Debug" Version="6.0.0" />
        <PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design" Version="6.0.4" />
    </ItemGroup>
</Project>

Nothing there looks suspicious, the only thing that looks suspect so far is that the host server reports using SDK 3.1.405. Could you try restarting the service & republishing, and/or installing https://dotnet.microsoft.com/en-us/download/dotnet/thank-you/sdk-6.0.300-windows-x64-installer on the host server and running again?

@wtgodbe Just to double check, the host doesn't normally need the SDK right, just the runtime?

I believe that's correct, though I'm not 100% sure, @BrennanConroy @halter73 or @Tratcher may be able to confirm.

Have you previously updated from e.g. 6.0.3 to 6.0.4 without issue? Or is this the first time you've done an in-place update within the 6.0 band? As best I can tell, @javiercn's suggestion about restarting/republishing is the most likely fix, as maybe the output directory of your app no longer matches what the project is expecting after updating to 6.0.5.

I updated the host to 6.0.5 but did not touch the app that's on 6.0.4 and threw the error. I have done multiple 6.0 band updates previously and haven't run into this before.

Did you install via the hosting bundle or via the standalone asp.net runtime installer?

This was the Windows hosting bundle.

Installing the 6.0.5 hosting bundle on a machine will remove any older 6.0.x runtimes & replace them with the 6.0.5 one - so if your running app had resolved the old 6.0.4 location of Microsoft.AspNetCore.WebUtilities.dll, then that would explain why it started failing to resolve that reference after you upgraded to 6.0.5. I believe restarting/republishing will fix your issue. CC @joeloff

That's interesting, and not something I would have suspected. Thanks for letting me know. I guess that means 6.0.4 apps can run on 6.0.5 hosts (no 6.0.4 installed) as long as those app services are restarted after the hosting bundle update?

That's my expectation, yes. In general, a X.Y.Z app should be able to run on any X.Y.N app, so long as N >= Z.

Take a look at https://docs.microsoft.com/dotnet/core/versions/selection#framework-dependent-apps-roll-forward for details of how roll forward works.

@wtgodbe Thank you.

@Pilchie I think the chances I would find a way to that documentation location are small, so thanks for pointing that out.

Sounds like if one application is updated on e.g. 6.x.x band, then all applications must either be updated or have their Windows service restarted, and 6.x.x band versions are backward compatible. Sound right?

In general there are a few things to consider:

1. Framework dependent app - Patch to the shared runtime: In this case, there should be no need to "update" or "recompile" the application for framework. Installing the new shared runtime will affect all apps on the machine that use that shared runtime install, but yes, they need to be restarted.
2. Framework dependent app - Patch to nuget package: Because nuget packages are deployed per app, each app that uses a particular nuget package will need to update and republish to get the contents of that nuget package in its publish folder, then deploy that to your server. This also implies restarting that app.
3. Self-contained app - Patch to shared runtime: In this case, because the shared runtime is included in the publish directory, you will need to update the SDK, republish and redeploy to your server. (It doesn't sound like you're using self-contained apps, but including for completeness).