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

samples/WebApi doesn't work with .NET Core 2.1 #5720

Closed
markrendle opened this Issue Apr 17, 2018 · 18 comments

Comments

Projects
None yet
7 participants
@markrendle

markrendle commented Apr 17, 2018

I encountered this on my own project, so I tried with the WebApi sample and got the same issue.

I tested before changing anything and everything worked.

I updated the csproj file to use 2.1 instead of 2.0, so it now looks like this:

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>netcoreapp2.1</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <RdXmlFile Include="rd.xml" />
  </ItemGroup>
  <ItemGroup>
    <Folder Include="wwwroot\" />
  </ItemGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore" Version="2.1.0-preview2-final" /> 
    <PackageReference Include="Microsoft.AspNetCore.Mvc.Core" Version="2.1.0-preview2-final" /> 
    <PackageReference Include="Microsoft.AspNetCore.Mvc.Formatters.Json" Version="2.1.0-preview2-final" />     
    <PackageReference Include="Microsoft.DotNet.ILCompiler" Version="1.0.0-alpha-*" />
  </ItemGroup>
</Project>

I had to remove the Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv entry from rd.xml because 2.1-preview2 no longer uses libuv.

With those changes, when I ran dotnet publish -c Release -r win-x64 I got the following output:

λ  dotnet publish -c Release -r win-x64
Microsoft (R) Build Engine version 15.6.22.57775 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Restore completed in 52.32 ms for C:\Labs\dotnet\corert\samples\WebApi\SampleWebApi.csproj.
  SampleWebApi -> C:\Labs\dotnet\corert\samples\WebApi\bin\Release\netcoreapp2.1\win-x64\SampleWebApi.dll
  Generating native code
EXEC : warning : RD.XML processing will change before release (https://github.com/dotnet/corert/issues/5001) [C:\Labs\dotnet\corert\samples\WebApi\SampleWebApi.csproj]
EXEC : error : [TEMPORARY EXCEPTION MESSAGE] ClassLoadGeneral: System.Reflection.Emit.ILGenerator, System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a [C:\Labs\dotnet\corert\samples\WebApi\SampleWebApi.csproj]
  Internal.TypeSystem.TypeSystemException+TypeLoadException: [TEMPORARY EXCEPTION MESSAGE] ClassLoadGeneral: System.Reflection.Emit.ILGenerator, System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
     at Internal.TypeSystem.ThrowHelper.ThrowTypeLoadException(ExceptionStringID id, String typeName, String assemblyName)
     at Internal.TypeSystem.Ecma.EcmaModule.GetType(String nameSpace, String name, Boolean throwIfNotFound)
     at Internal.TypeSystem.Ecma.EcmaModule.GetType(String nameSpace, String name, Boolean throwIfNotFound)
     at Internal.TypeSystem.Ecma.EcmaModule.ResolveTypeReference(TypeReferenceHandle handle)
     at Internal.TypeSystem.Ecma.EcmaModule.EcmaObjectLookupHashtable.CreateValueFromKey(EntityHandle handle)
     at Internal.TypeSystem.LockFreeReaderHashtable`2.CreateValueAndEnsureValueIsInTable(TKey key)
     at Internal.TypeSystem.Ecma.EcmaModule.GetObject(EntityHandle handle)
     at Internal.TypeSystem.Ecma.EcmaModule.GetType(EntityHandle handle)
     at Internal.TypeSystem.Ecma.EcmaSignatureParser.ParseType(SignatureTypeCode typeCode)
     at Internal.TypeSystem.Ecma.EcmaSignatureParser.ParseFieldSignature()
     at Internal.TypeSystem.Ecma.EcmaField.InitializeFieldType()
     at Internal.TypeSystem.MetadataFieldLayoutAlgorithm.ComputeInstanceLayout(DefType defType, InstanceLayoutKind layoutKind)
     at Internal.TypeSystem.DefType.ComputeInstanceLayout(InstanceLayoutKind layoutKind)
     at ILCompiler.DependencyAnalysis.EETypeNode.CheckCanGenerateEEType(NodeFactory factory, TypeDesc type)
     at ILCompiler.DependencyAnalysis.NodeFactory.<CreateNodeCaches>b__36_1(TypeDesc type)
     at System.Collections.Concurrent.ConcurrentDictionary`2.GetOrAdd(TKey key, Func`2 valueFactory)
     at ILCompiler.Compilation.RootingServiceProvider.AddCompilationRoot(TypeDesc type, String reason)
     at ILCompiler.RdXmlRootProvider.RootType(IRootingServiceProvider rootProvider, TypeDesc type)
     at ILCompiler.RdXmlRootProvider.ProcessAssemblyDirective(IRootingServiceProvider rootProvider, XElement assemblyElement)
     at ILCompiler.RdXmlRootProvider.AddCompilationRoots(IRootingServiceProvider rootProvider)
     at ILCompiler.Compilation..ctor(DependencyAnalyzerBase`1 dependencyGraph, NodeFactory nodeFactory, IEnumerable`1 compilationRoots, DebugInformationProvider debugInformationProvider, DevirtualizationManager devirtualizationManager, Logger logger)
     at ILCompiler.ILScannerBuilder.ToILScanner()
     at ILCompiler.Program.Run(String[] args)
     at ILCompiler.Program.Main(String[] args)
C:\Users\mark\.nuget\packages\microsoft.dotnet.ilcompiler\1.0.0-alpha-26417-01\build\Microsoft.NETCore.Native.targets(172,5): error MSB3073: The command ""C:\Users\mark\.nuget\packages\runtime.win-x64.microsoft.dotnet.ilcompiler\1.0.0-alpha-26417-01\tools\ilc" @"obj\Release\netcoreapp2.1\win-x64\native\SampleWebApi.ilc.rsp"" exited with code 1. [C:\Labs\dotnet\corert\samples\WebApi\SampleWebApi.csproj]

Environment info

Windows 10 Pro 1709 Build 16299.371

$ dotnet --version
2.1.300-preview2-008530
@jkotas

This comment has been minimized.

Member

jkotas commented Apr 17, 2018

ASP.NET dependency injection introduced dependency on Reflection.Emit in aspnet/DependencyInjection#630 unfortunately. It makes it incompatible with CoreRT.

We can make it functional in CoreRT AOT environment by introducing IL interpretter (#5011), but it would still perform poorly. The dependency injection framework is using Reflection.Emit on performance critical paths.

It would be really up to ASP.NET to provide AOT-friendly flavor that generates all code at build time instead of runtime to make this work well. It would likely help the startup without CoreRT as well.

@markrendle

This comment has been minimized.

markrendle commented Apr 17, 2018

That's annoying. Thanks for the explanation though.

@jkotas

This comment has been minimized.

Member

jkotas commented Apr 18, 2018

It may be possible to workaround this by using netstandard2.0 build of DependencyInjection that does not have the dependency on Reflection.Emit: https://github.com/aspnet/DependencyInjection/pull/630/files#diff-499bed1ac3743837d217bcbe8bad072fR9

@morganbr

This comment has been minimized.

Contributor

morganbr commented Apr 18, 2018

It looks like ASP.NET might have also kept the expression-based DI engine based on ServiceProviderOptions.Mode (along with a couple other modes that might be faster than expressions while still AoT friendly). I'd suggest seeing if there's a way to control that from user code.

@markrendle

This comment has been minimized.

markrendle commented Apr 19, 2018

Is there any way I can force the build to use the netstandard2.0 DLL over the netcoreapp one when my console application is targeting netcoreapp?

@markrendle

This comment has been minimized.

markrendle commented Apr 19, 2018

Hmm... outside of the incredibly hacky "add a pre-build step to modify the project.assets.json file and change the compile and runtime entries on the target to netstandard2.0 instead of netcoreapp2.0" approach, that is.

I'm away from my project at the moment, but I'll try that when I get back to it.

@davidfowl

This comment has been minimized.

Contributor

davidfowl commented Apr 23, 2018

If only we had this dotnet/corefx#10470 😏

@Fabi

This comment has been minimized.

Fabi commented Apr 29, 2018

Actually this also breaks some other projects that are not using Microsoft.AspNetCore* namespaces directly. This is a bit annoying^^

Btw: It also happens when using netcoreapp2.0

@Fabi

This comment has been minimized.

Fabi commented May 28, 2018

This issue seems to be fixed? Just tested it and it works fine.

@MichalStrehovsky

This comment has been minimized.

Member

MichalStrehovsky commented May 28, 2018

@Fabi according to a comment in aspnet/home#3079 we should really be fine for 2.1. Thanks for verifying this!

@benaadams

This comment has been minimized.

Contributor

benaadams commented Jun 7, 2018

Doesn't work for 2.1

@davidfowl

This comment has been minimized.

Contributor

davidfowl commented Jun 8, 2018

Probably another issue

@benaadams

This comment has been minimized.

Contributor

benaadams commented Jun 8, 2018

Same issue

  Generating native code
EXEC : error : [TEMPORARY EXCEPTION MESSAGE] ClassLoadGeneral:
 System.Reflection.Emit.ILGenerator, System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a [C:\....csproj]
  Internal.TypeSystem.TypeSystemException+TypeLoadException: [TEMPORARY EXCEPTION MESSAGE] ClassLoadGeneral: System.Reflection.Emit.ILGenerator, System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
     at Internal.TypeSystem.ThrowHelper.ThrowTypeLoadException(ExceptionStringID id, String typeName, String assemblyName)
     at Internal.TypeSystem.Ecma.EcmaModule.GetType(String nameSpace, String name, Boolean throwIfNotFound)
     at Internal.TypeSystem.Ecma.EcmaModule.GetType(String nameSpace, String name, Boolean throwIfNotFound)
     at Internal.TypeSystem.Ecma.EcmaModule.ResolveTypeReference(TypeReferenceHandle handle)
     at Internal.TypeSystem.Ecma.EcmaModule.EcmaObjectLookupHashtable.CreateValueFromKey(EntityHandle handle)
     at Internal.TypeSystem.LockFreeReaderHashtable`2.CreateValueAndEnsureValueIsInTable(TKey key)
     at Internal.TypeSystem.Ecma.EcmaModule.GetObject(EntityHandle handle)
     at Internal.TypeSystem.Ecma.EcmaModule.GetType(EntityHandle handle)
     at Internal.TypeSystem.Ecma.EcmaSignatureParser.ParseType(SignatureTypeCode typeCode)
     at Internal.TypeSystem.Ecma.EcmaSignatureParser.ParseFieldSignature()
     at Internal.TypeSystem.Ecma.EcmaField.InitializeFieldType()
     at Internal.TypeSystem.MetadataFieldLayoutAlgorithm.ComputeInstanceLayout(DefType defType, InstanceLayoutKind layoutKind)
     at Internal.TypeSystem.DefType.ComputeInstanceLayout(InstanceLayoutKind layoutKind)
     at ILCompiler.DependencyAnalysis.EETypeNode.CheckCanGenerateEEType(NodeFactory factory, TypeDesc type)
     at ILCompiler.DependencyAnalysis.NodeFactory.<CreateNodeCaches>b__36_0(TypeDesc type)
     at System.Collections.Concurrent.ConcurrentDictionary`2.GetOrAdd(TKey key, Func`2 valueFactory)
     at ILCompiler.DependencyAnalysis.GenericCompositionNode.GetData(NodeFactory factory, Boolean relocsOnly)
     at ILCompiler.DependencyAnalysis.ObjectNode.GetStaticDependencies(NodeFactory factory)
     at ILCompiler.DependencyAnalysisFramework.DependencyAnalyzer`2.GetStaticDependenciesImpl(DependencyNodeCore`1 node)
     at ILCompiler.DependencyAnalysisFramework.DependencyAnalyzer`2.ProcessMarkStack()
     at ILCompiler.DependencyAnalysisFramework.DependencyAnalyzer`2.ComputeMarkedNodes()
     at ILCompiler.ILScanner.ILCompiler.IILScanner.Scan()
     at ILCompiler.Program.Run(String[] args)
     at ILCompiler.Program.Main(String[] args)
@davidfowl

This comment has been minimized.

Contributor

davidfowl commented Jun 8, 2018

I wonder if it's barfing at the reference itself. I would hope not...

@benaadams

This comment has been minimized.

Contributor

benaadams commented Jun 8, 2018

For what I'm trying to build the only use/reference of DI would be via WebHostBuilder with the indirect reference from Hosting

image

I'm trying to build the PlatformBenchmark with json and db stuff stripped out, so is very basic and doesn't use DI directly.

However I have updated the Sample to show the issue #5912

@MichalStrehovsky

This comment has been minimized.

Member

MichalStrehovsky commented Jun 8, 2018

The compiler is crashing because the facade assemblies that CoreFX is generating for Ref.Emit are bogus.

I filed #5913 on the compiler crash (we shouldn't crash), but this would ideally be fixed by making the Ref.Emit behave like any other other API we don't currently support in CoreRT (i.e. a bunch of PlatformNotSupportedException-throwing methods instead of a bogus facade that doesn't have things in it).

@MichalStrehovsky

This comment has been minimized.

Member

MichalStrehovsky commented Jun 14, 2018

The compiler is crashing because the facade assemblies that CoreFX is generating for Ref.Emit are bogus.

We're waiting for dotnet/corefx#30338 to get through. After that, we'll pick up the latest CoreFX and the problem with bogus Ref.Emit facades should be gone.

@MichalStrehovsky

This comment has been minimized.

Member

MichalStrehovsky commented Jun 17, 2018

#5953 has the fixes to CoreFX that should make this compile again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment