SDK regression in 3.0.101 and 3.1.100 for ASP.NET Core workloads

[jkotalik]

SDK regression in 3.0.101 and 3.1.100 for ASP.NET Core workloads

The 3.0.101 and 3.1.100 versions of the .NET Core SDK have a regression which potentially causes 2.2 and 3.0/3.1 dependencies to mismatch, causing applications to fail to start when running with IIS InProcess.

For the official announcement, see aspnet/Announcements#398.

Version introduced

.NET Core SDK 3.0.101

.NET Core SDK 3.1.100

Regression details

In 3.0, we introduced the concept of a FrameworkReference for ASP.NET Core. The FrameworkReference includes all the libraries that make up ASP.NET Core. See aspnet/Announcements#325 for the motivation and reason behind this change. For all libraries that are referenced in the Microsoft.AspNetCore.App framework, we ignore references in your project of a lower version. For example, if a 2.2 version of Microsoft.AspNetCore.Server.Kestrel (one of the libraries in the framework) is also separately referenced by the application, we ignore the 2.2 version when building. These update rules are defined by the PlatformManifest.txt file is part of the SDK. Any library in that list has this behavior, earlier references to those libraries are ignored.

However, in 3.0.1 and 3.1.0, we introduced a regression which removed a few select references from the PlatformManifest.txt file by mistake.

Libraries that were removed from the PlatformManifest.txt between 3.0.0 and 3.0.1:

• aspnetcorev2_inprocess.dll (previously part of the Microsoft.AspNetCore.Server.IIS package)
• System.Drawing.Common.dll
• Microsoft.Win32.SystemEvents.dll
• System.Security.Cryptography.Pkcs.dll

Libraries that were added to the PlatformManifest.txt between 3.0.0 and 3.0.1:

• Microsoft.Win32.Registry.dll
• System.Security.AccessControl.dll
• System.Security.Cryptography.Cng.dll
• System.Security.Principal.Windows.dll

The libraries that were added to the PlatformManifest.txt shouldn't adversely affect applications. However, the dependencies removed do affect applications. In particular, the aspnetcorev2_inprocess.dll native library is critical to IIS in-process hosting. Issues with this have been reported in a few places (for example #17662). We've now identified this is a broader regression.

If an application references (directly or transitively) a previous version of the Microsoft.AspNetCore.Server.IIS, System.Drawing.Common, Microsoft.Win32.SystemEvents, or System.Security.Cryptography.Pkcs package, it might deploy the older dependency rather than the 3.0/3.1 dependency. This can cause assembly load failures.

Workarounds

Users may work around this issue by doing one of the following:

Remove all direct and indirect references to the affected packages.

The following packages include the aspnetcorev2_inprocess.dll native library:

• Microsoft.AspNetCore
• Microsoft.AspNetCore.Server.IIS

Other affected libraries are contained in packages with the same name. See the above lists.

The resolution is to remove these package references from your application. Be aware that they may be transitive dependencies (dependencies of other packages you depend upon).

Avoid publishing incorrect package content

If you cannot remove earlier versions of the pacakges, you can explicitly suppress those packages from publishing using ExcludeAssets:

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
     <PackageReference Include="Microsoft.AspNetCore.Server.IIS" Version="2.2.6" ExcludeAssets="All" /> 
  </ItemGroup>

</Project>

We recommend clearing out bin/obj folders before building with the above fix.

[mxa0079]

We are not sure if the problem we are running into currently is related to this issue. (Identity Server project runs without a problem iun dev mahcine but fails to start in Azure App Service instance. It was working a couple of weeks ago...) Could you provide more information about the symptoms caused by this regression?

[Pilchie]

@mxa0079 it's more likely that your issue is related to aspnet/Announcements#401.

Likely you have the 3.1.1 runtime on your local dev machines, but App Service only has 3.1.0. Right now, if you are using a 3.1.1 package, it might fail on the unpatched 3.1.0 runtime.

[AndreiKhotko]

I am trying to migrate my projects from .net core 2.2 to 3.1. And the problem was occurred when trying to publish the apps in IIS InProcess and with --self-contained false option. The error is:

Error 500.31 - ANCM Failed to Find Native Dependencies in IIS

Common solutions to this issue: The specified version of Microsoft.NetCore.App or Microsoft.AspNetCore.App was not found.

Specific error detected by ANCM: A fatal error was encountered. The library 'hostpolicy.dll' required to execute the application was not found in $pathToPublishedAppFolder.

Failed to run as a self-contained app. If this should be a framework-dependent app, specify the appropriate framework in $pathToPublishedAppFolder$projectName.runtimeconfig.json

For more details please see my question on stackoverflow: link

What is the root of a problem? I've tried everything, nothings seems to work :(

[Pilchie]

@joeloff - this looks like the hosting bundle problem right?

@AndreiKhotko - can you try a Repair on the .NET Core Runtime in Add/Remove Programs?

[joeloff]

@Pilchie Which hosting bundle problem?

[Pilchie]

I was thinking of the issue where we had the non-final branded runtime in the hosting bundle coupled with dotnet/runtime#703.

[joeloff]

Ahh, if that issue is the culprit then repair would be a good option. Should be easy to tell because some of the runtime files would be missing and then placed back after the repair

[AndreiKhotko]

@Pilchie I tried it. It doesn't help at all. I know that the problem is occurred when I build the solution with a command:

dotnet build $solutionPath -r $targetPlatform -c Debug -v q --configfile $nugetConfigFile

And then publish the app with --no-build param:

dotnet publish $projectPath --no-build -c Debug -o $destinationPath -v q -r $targetPlatform --self-contained false;

And then when server tried to run the app, the error is occurred Error 500.31 - ANCM Failed to Find Native Dependencies in IIS.
Somehow after publishing the app the file *.runtime.config contains both Microsoft.NETCore.App and Microsoft.AspNetCore.App:

{
  "runtimeOptions": {
    "tfm": "netcoreapp3.1",
    "includedFrameworks": [
      {
        "name": "Microsoft.NETCore.App",
        "version": "3.1.1"
      },
      {
        "name": "Microsoft.AspNetCore.App",
        "version": "3.1.1"
      }
    ],
    "configProperties": {
      "System.GC.Server": true
    }
  }
}

The interesting thing is that when I publish app without --no-build option, the application will work on IIS.

Maybe I could not understand how to use the commands, but my aim is to build the whole solution, and then publish the project on IIS without build in Framework Dependent Executable (FDE) mode. The target platform for me can be either linux-64 (CentOS) or win-x64. Should I have to change the commands?

This problem has not been reproduced when I use .net core 2.2 sdk and .net core 2.2 apps. The app has been published and run successfully. Feel a little bit confused

[Pilchie]

@jkotalik - any idea?

Note - you can't run the linux-x64 binaries on IIS, because IIS is windows specific. If you want to run on Linux, you'd need to use Kestrel.

[AndreiKhotko]

@Pilchie that's obvious. When the project is published on linux, I use linux-x64 identifier, and when on windows IIS - then win-x64.

[jkotalik]

I'm not sure what the interaction between dotnet publish and --no-build is. @nguerrera any insights?

[jkotalik]

This issue has been fixed in 3.1.2. Keeping open for the sake of having a matching issue for annoucements.

[nguerrera]

I'm not sure what the interaction between dotnet publish and --no-build is. @nguerrera any insights?

There should have been an error if you introduced a new rid, did not restore differently, and used --no-build. @dsplaisted