Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
jkotalik opened this issue Dec 19, 2019 · 13 comments
Open

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

jkotalik opened this issue Dec 19, 2019 · 13 comments
Labels
Milestone

Comments

@jkotalik
Copy link
Member

@jkotalik jkotalik commented Dec 19, 2019

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

This comment has been minimized.

Copy link

@mxa0079 mxa0079 commented Jan 22, 2020

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

This comment has been minimized.

Copy link
Member

@Pilchie Pilchie commented Jan 22, 2020

@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

This comment has been minimized.

Copy link

@AndreiKhotko AndreiKhotko commented Jan 23, 2020

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

This comment has been minimized.

Copy link
Member

@Pilchie Pilchie commented Jan 23, 2020

@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

This comment has been minimized.

Copy link
Contributor

@joeloff joeloff commented Jan 23, 2020

@Pilchie Which hosting bundle problem?

@Pilchie

This comment has been minimized.

Copy link
Member

@Pilchie Pilchie commented Jan 23, 2020

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

@joeloff

This comment has been minimized.

Copy link
Contributor

@joeloff joeloff commented Jan 23, 2020

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

This comment has been minimized.

Copy link

@AndreiKhotko AndreiKhotko commented Jan 24, 2020

@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

This comment has been minimized.

Copy link
Member

@Pilchie Pilchie commented Jan 24, 2020

@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

This comment has been minimized.

Copy link

@AndreiKhotko AndreiKhotko commented Jan 27, 2020

@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

This comment has been minimized.

Copy link
Member Author

@jkotalik jkotalik commented Jan 29, 2020

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

@jkotalik

This comment has been minimized.

Copy link
Member Author

@jkotalik jkotalik commented Feb 18, 2020

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

@jkotalik jkotalik unpinned this issue Feb 18, 2020
@nguerrera

This comment has been minimized.

Copy link
Member

@nguerrera nguerrera commented Feb 18, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants
You can’t perform that action at this time.