Dotnet core 2.1 rc-1 won't load projects targeting net461

[livarcocc]

From @Petermarcu on May 9, 2018 15:31

@dloukola commented on Wed May 09 2018

I have been working with dotnet core 2.1 preview 2 and earlier without issues. Installing the dotnet core 2.1 rc-1 SDK causes my webapi projects that are targeting 4.6.1 framework to fail to load.

It fails in the Startup at ConfigureServices when calling services.AddMvcCore().

The error message is: "the given key was not present in the dictionary" It seems to error out in the stack trace at: "DefaultAssemblyPartDiscoveryProvider"

Uninstalling the 2.1 SDK makes everything work again, so it's definitely the issue.

I am targeting some aspnet core 1.* versions...maybe that is the issue? Example: Microsoft.AspNetCore.Authentication.JwtBearer (1.1.1) Microsoft.AspNetCore.Diagnostics (1.1.1) Microsoft.AspNetCore.Mvc (1.1.2) Microsoft.AspNetCore.Routing (1.1.1) Microsoft.AspNetCore.Server.IISIntegration (1.1.1) Microsoft.AspNetCore..Server.Kestrel (1.1.1)

Any ideas?

---

@thyams commented on Wed May 09 2018

Try replacing the AspNetCore 1.0 packages with AspNetCore.All (v2.0.8),

---

@dloukola commented on Wed May 09 2018

@thyams I have a plan to try that. However, I have no current intention to migrate that project to core 2.0. Installing a SDK shouldn't break older projects. I'm not referencing and 2.1-rc1 nuget packages in that project. 2.1 preview 2 didn't have this issue.

---

@thyams commented on Wed May 09 2018

It might be the configuration / startup change. Try this change (without package updates):

Thats kestrel running successfully running a brand new project utilizing everything NetCore 2.0 (so no old packages) but try with your setup.

AddMvcCore() is a little different then just utilizing AddMvc()

---

@dloukola commented on Wed May 09 2018

I appreciate the thought of updating...but like I said previously, I think we need a workaround that will allow the 2.1 sdk installed without having to change apps that aren't using 2.1. I have tried adding global.json files all over the place to no avail.

Copied from original issue: dotnet/cli#9241

[livarcocc]

From @Petermarcu on May 9, 2018 15:32

@livarcocc can you have someone take a look? Installing 2.1.300 shouldn't break people's existing 4.6 webapi projects.

[livarcocc]

I believe this issue should be looked at first by asp.net. Moving it there. If it is confirmed to be an SDK issue, this one can be re-activated.

[Tratcher]

What does your full csproj look like?

[pranavkm]

Might be a dup of this - https://github.com/aspnet/Mvc/issues/5690. Could you also share the deps file - bin\Debug\net461\WebApplication.deps.json?

[muratg]

@dloukola Is this a mixture of 1.x and 2.0.x stuff? Can you paste see a .csproj file?

[muratg]

@dloukola If you're unable to paste a csproj, could you tell us what .NET Core Runtime version you're using for your app?

cc @JunTaoLuo

[dloukola]

Hi @muratg, My csproj is pasted below with some names masked.

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

  <PropertyGroup Label="Globals">
    <SccProjectName>SAK</SccProjectName>
    <SccProvider>SAK</SccProvider>
    <SccAuxPath>SAK</SccAuxPath>
    <SccLocalPath>SAK</SccLocalPath>
  </PropertyGroup>

  <PropertyGroup>
    <Description>ASP.NET Web API</Description>
    <AssemblyTitle>[my-project-name]</AssemblyTitle>
    <TargetFramework>net461</TargetFramework>
    <PreserveCompilationContext>true</PreserveCompilationContext>
    <AssemblyName></AssemblyName>
    <OutputType>Exe</OutputType>
    <PackageId>[my-project-name]</PackageId>
    <RuntimeIdentifiers>win7-x64</RuntimeIdentifiers>
    <ApplicationInsightsResourceId>[my-ai]</ApplicationInsightsResourceId>
    <ApplicationInsightsAnnotationResourceId>[my-ai]]</ApplicationInsightsAnnotationResourceId>
  </PropertyGroup>

  <ItemGroup>
    <None Include="App.config" />    
    <None Update="wwwroot\**\*">
      <CopyToPublishDirectory>PreserveNewest</CopyToPublishDirectory>
    </None>    
  </ItemGroup>

  <ItemGroup>
    <ProjectReference Include="..\[my-project-ref1.csproj" />
    <ProjectReference Include="..\[my-project-ref2].csproj" />
    <ProjectReference Include="..\[my-project-ref3].csproj" />
    <ProjectReference Include="..\[my-project-ref4].csproj" />
  </ItemGroup>

  <ItemGroup>
    <PackageReference Include="HtmlSanitizer" Version="4.0.181" />
    <PackageReference Include="IdentityServer4.AccessTokenValidation" Version="1.2.0" />
    <PackageReference Include="[my-package1]" Version="1.1.0-build-20180223-02" />
    <PackageReference Include="[my-package2]" Version="1.0.0-build-20180504-01" />
    <PackageReference Include="[my-package3]" Version="1.0.0" />
    <PackageReference Include="[my-package4]" Version="1.0.0" />
    <PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.1.2" />
    <PackageReference Include="Microsoft.AspNetCore.Routing" Version="1.1.1" />
    <PackageReference Include="Microsoft.AspNetCore.Server.IISIntegration" Version="1.1.1" />
    <PackageReference Include="Microsoft.AspNetCore.Server.Kestrel" Version="1.1.1" />
    <PackageReference Include="Microsoft.Extensions.Configuration.CommandLine" Version="1.1.2" />
    <PackageReference Include="Microsoft.Extensions.Configuration.EnvironmentVariables" Version="1.1.2" />
    <PackageReference Include="Microsoft.Extensions.Configuration.FileExtensions" Version="1.1.2" />
    <PackageReference Include="Microsoft.Extensions.Configuration.Json" Version="1.1.2" />
    <PackageReference Include="Microsoft.Extensions.Logging" Version="1.1.2" />
    <PackageReference Include="Microsoft.Extensions.Logging.Console" Version="1.1.2" />
    <PackageReference Include="Microsoft.Extensions.Logging.Debug" Version="1.1.2" />
    <PackageReference Include="Microsoft.Extensions.Options.ConfigurationExtensions" Version="1.1.2" />
    <PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.0.1" />
    <PackageReference Include="Microsoft.AspNetCore.Diagnostics" Version="1.1.1" />
    <PackageReference Include="Microsoft.Extensions.Logging.AzureAppServices" Version="1.0.1" />
    <PackageReference Include="Microsoft.AspNetCore.Authentication.JwtBearer" Version="1.1.1" />
  </ItemGroup>

  <ItemGroup Condition=" '$(TargetFramework)' == 'net461' ">
    <Reference Include="System" />
    <Reference Include="Microsoft.CSharp" />
  </ItemGroup>

  <ItemGroup>
    <DotNetCliToolReference Include="Microsoft.DotNet.Watcher.Tools" Version="1.0.0" />
  </ItemGroup> 

  <ItemGroup>
    <Content Update="appsettings.json">
      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
    </Content>
  </ItemGroup> 

  <ItemGroup>
    <WCFMetadata Include="Connected Services" />
  </ItemGroup>

  <ItemGroup>
    <None Include="app_data\\jobs\\**\\*.*">
      <CopyToPublishDirectory>PreserveNewest</CopyToPublishDirectory>
    </None>
  </ItemGroup>

</Project>

[Tratcher]

The csproj looks fine. Can you include the full exception stack trace please?

[dloukola]

Message The given key was not present in the dictionary.

Source mscorlib

StackTrace

   at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
   at Microsoft.AspNetCore.Mvc.Internal.DefaultAssemblyPartDiscoveryProvider.CandidateResolver.ComputeClassification(String dependency)
   at Microsoft.AspNetCore.Mvc.Internal.DefaultAssemblyPartDiscoveryProvider.CandidateResolver.ComputeClassification(String dependency)
   at Microsoft.AspNetCore.Mvc.Internal.DefaultAssemblyPartDiscoveryProvider.CandidateResolver.ComputeClassification(String dependency)
   at Microsoft.AspNetCore.Mvc.Internal.DefaultAssemblyPartDiscoveryProvider.CandidateResolver.<GetCandidates>d__4.MoveNext()
   at System.Linq.Enumerable.<SelectManyIterator>d__17`2.MoveNext()
   at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()
   at Microsoft.Extensions.DependencyInjection.MvcCoreServiceCollectionExtensions.GetApplicationPartManager(IServiceCollection services)
   at Microsoft.Extensions.DependencyInjection.MvcCoreServiceCollectionExtensions.AddMvcCore(IServiceCollection services)
   at MyProject.Startup.ConfigureServices(IServiceCollection services)

[dloukola]

Please keep in mind that this worked fine with the 2.1 preview 2 SDK. This is an issue that started in 2.1 rc-1. So something must have changed to cause this.

[Tratcher]

Src: https://github.com/aspnet/Mvc/blob/d4cd453a9d5b5b27ab6062d55a06a62f988b5541/src/Microsoft.AspNetCore.Mvc.Core/Internal/DefaultAssemblyPartDiscoveryProvider.cs#L93-L95

@pranavkm can you take a look?

[pranavkm]

Could you also share the deps file - bin\Debug\net461\win7-x64\WebApplication.deps.json?

[dloukola]

Deps file content: https://gist.github.com/pranavkm/fec9097812a9ba42d71942bd25023bc1

[pranavkm]

Yup, this is a dup of https://github.com/aspnet/Mvc/issues/5690. The 2.1 Sdk adds additional dependencies in the deps file (e.g. "System.AppContext.Reference": "4.1.2.0"). Unfortunately, Mvc 1.0 \ 1.1 have a bug where they do not ignore these and you get the exception that's seen here. We'd need to port https://github.com/aspnet/Mvc/commit/3f2fd6f0c7841c44b4e7549cc84e6890eb62c0b8 to 1.0\1.1 to address this in code.

Upgrading to ASP.NET Core 2.0 should fix this. Other alternatives would be

a) To add a global.json to your solution and specify an older Sdk b) You could manually do Mvc's assembly part discovery and add an ApplicationPartManager instance before calling AddMvc(). Might look like:

var manager = new ApplicationPartManager();
manager.ApplicationParts.Add(new AssemblyPart(typeof(Startup).Assembly));
manager.ApplicationParts.Add(new AssemblyPart(typeof(Project1.Project1Type).Assembly));

services.AddSingleton(manager);
services.AddMvc();

@livarcocc are the .References libraries intentionally there (for roll forwards ❓) or is this a point-in-time issue?

[dloukola]

Can you please provide an example of a global.json and where exactly I should put that file? That was actually my first attempt at solving the problem, but I didn't have success with it.

[livarcocc]

@dsplaisted can you answer @pranavkm's question about the reference libraries in the deps.json?

[livarcocc]

@dloukola here is an example of a global.json:

{
  "sdk": {
    "version": "2.1.200"
  }
}

You should put it in the root of your repo, so that all your projects use the same SDK. Not that with the SDK I put above, you won't be able to target netcoreapp2.1.

[dloukola]

So...the global.json approach does not work... I put files in 4 different parts of the hierarchy and none of them solve it.

[dloukola]

Sorry, I take that back. I tried one more place and it worked!! Thanks everybody!

[dsplaisted]

@dloukola global.json should go in a folder which is an ancestor of all of the projects you are building. The root of your repo is generally where you want to put it.

[pranavkm]

@dsplaisted getting back to my question, are the new libraries showing up intentional? If so, I can file an issue in Mvc to consider porting our patch.

[dsplaisted]

@pranavkm It is expected that there could be entries in the deps file ending with .Reference if there are collisions in names between referenced libraries and packages. This was added in 2.0 in https://github.com/dotnet/sdk/issues/1289.

But that probably wasn't the question you were asking. What specific references are getting added that aren't expected? Is there a regression in recent builds of the SDK? Is there a minimal repro of the issue?

[pranavkm]

@pranavkm It is expected that there could be entries in the deps file ending with .Reference if there are collisions in names between referenced libraries and packages. This was added in 2.0 in dotnet/sdk#1289.

That's primarily what I was looking at. We had a bug in Mvc 1.0 \ 1.1 where we assumed every dependency must also appear as a runtime library, which isn't true for any of the .Reference libraries. I'll file an issue for us to port the fix to a patch.

[robertmuehsig]

We had the same issue with our ASP.NET Core 1.1 app (running on .NET Framework 4.5.2 :-/) and the "code" patch seems to work:

var manager = new ApplicationPartManager();
manager.ApplicationParts.Add(new AssemblyPart(typeof(Startup).Assembly));
manager.ApplicationParts.Add(new AssemblyPart(typeof(Project1.Project1Type).Assembly));

services.AddSingleton(manager);
services.AddMvc();

Thanks @pranavkm

[shadowmint]

Also affected by this; this is a surprising breaking change for dot point release.

For anyone else who finds this ticket, you can see what ApplicationPartManager is, and what it should be doing, rather than just copy-pasting random code in the hopes it'll somehow fix things by reading:

https://docs.microsoft.com/en-us/aspnet/core/mvc/advanced/app-parts?view=aspnetcore-2.1

...and lets be totally clear here: This is a bug.

serivces.AddMvc() shouldn't throw an exception by default.

[mattfrear]

This is absolute dogshit. Installing a new SDK (2.1) should not break an old one.

[davidfowl]

@mattfrear agreed, in general we do our best to avoid that. Did your ASP.NET Core 1.x application break after updating the SDK? Did you try the workaround?

[mattfrear]

@davidfowl I came here after raising a separate issue (https://github.com/Azure/service-fabric-issues/issues/1086) which was linked to above. I figured out one of the workarounds myself - to upgrade to ASP.NET Core 2.0, and spent ~2 days doing that across a bunch of our services.

We are using VSTS for our builds so we didn't change anything. Evidently the VSTS team must have installed .NET Core 2.1, which then started breaking our deployments through no fault of ours.

The global.json workaround looks simpler, wish I'd read that sooner. Upgrading to ASP.NET Core 2.0 is on our backlog anyway, so it wasn't a complete waste of time, but it wasn't nice being rushed to do that right now.

[spottedmahn]

Did your ASP.NET Core 1.x application break after updating the SDK?

Yes, our 1.1 app did break after installing the 2.1 SDK.

I don't think global.json is a great option b/c everyone on the team would have the exact same version, right? Please correct me if I'm wrong.

I think I'll uninstall the 2.1 SDK for now 😢

[davidfowl]

I don't think global.json is a great option b/c everyone on the team would have the exact same version, right? Please correct me if I'm wrong.

Why is that a bad thing? Doesn't that exactly solve the problem?

[spottedmahn]

Why is that a bad thing?

My teammates most likely have different versions of the 1.X SDK installed and I will break numerous other devs until they install that specific 1.X version. It's a good thing in that we would all have the same SDK.

* Unless there's some way to tell it to use any 1.X SDK version?

I thought about it some more and I could just add global.json to .gitignore to fix it for me w/o affecting others.

Doesn't that exactly solve the problem?

Yes, it solved my problem.

[ramandeep-singh-1983]

Well i wasted half a day when my new build on VSTS failed repeatedly. Sad to see such a defect come up and ruin our existing builds. Good to have some workaround to make it up and working again, phew!

[WouterVanherck]

Everyone should check out @pranavkm answers of May 10
They're a LIFE SAVER

[k7hpn]

We are seeing this in our core projects targeting net461 after installing the latest .NET Core 2.1 SDK (v2.1.301). Putting the global.json next to the solution file specifying SDK verison 1.1.0 or 2.1.200 seems to fix it. Would have saved a lot of time if this breaking change had been notated somewhere in the new SDK install!

[dsplaisted]

This should be fixed in the 2.1.400 release of the .NET Core SDK.

@pranavkm @natemcmaster Can someone close this issue? I don't have permission on this repo.

[johndoryforglory]

hi for clarification: does the fix in .NET Core SDK 2.1.400 resolve the problem with Core MVC not working over .NET Framework 4.6?

[pranavkm]

does the fix in .NET Core SDK 2.1.400 resolve the problem with Core MVC not working over .NET Framework 4.6?

It specifically fixes this exception - https://github.com/aspnet/Home/issues/3132#issuecomment-388044634. If there are other issues you are running in to using ASP.NET Core MVC with the 2.1.x SDK, please file an issue at https://github.com/aspnet/Mvc/issues

[fschmied]

@pranavkm Can you confirm this is definitely fixed in 2.1.400? I'm seeing the KeyNotFoundException with .NET Core SDK 2.1.400 (installed with VS 15.8). Repro solution at https://files.fm/u/xuc446ug

[pspkshah]

Hey Hey, I got the solution for the same issue, if any of your application targeting to .net Framework 4.6.1 and you wants to install, .net Core SDK (in my case I installed dotnet-sdk-2.1.302-win-x64.exe ).

Solution: just change your .net Framework to 4.7.1, and everything will work fine, without changing any of the code.

Cause: What I understood about the issue is, there is problem with .net Framework 4.6.x where its not able to find their assembly and getting conflict with .net core SDK. since, .net framework 4.7.x has .core features in build, it differentiates and things gets managed.

Issue, which is mentioned at very beginning, @Petermarcu , same issue I was getting.

Here, I was able to open, edit and commit all my changes, even I was able to build project as well, but when I start running my application from Host project (startup project / default project)

var host = new WebHostBuilder() .UseKestrel() .UseContentRoot(Directory.GetCurrentDirectory()) .UseIISIntegration() .UseStartup() .Build();

**host.Run();  --> Host is not able to initialising project, due wrong referencing**

Applying above solution if anyone facing similar issue, comment on this, will resolve !!!

[msgallagher]

Can you confirm this is definitely fixed in 2.1.400? I'm seeing the KeyNotFoundException with .NET Core SDK 2.1.400 (installed with VS 15.8). Repro solution at https://files.fm/u/xuc446ug

I am still getting exception with SDK 2.1.400 - had to use global.json in root directory to work-around this issue.

[pspkshah]

@msgallagher in my case its not, because my existing project was targeting to .net Framework 4.6.1 and I have created another project with SDK 2.1.X and both are perfectly working fine.

Repeating again I just, changed existing projects target framework from 4.6.X to 4.7.X.

[pspkshah]

@msgallagher I will check your Repro solution, and confirm on the same shortly.

[georgevella]

Hi

We encountered this same issue on one of our apps targetting .NET 4.7. Our last production build in April produced a working deployable, but recent builds in test are failing with the KeyNotFoundException.

This codebase is quiet stable and doesn't change frequently so we don't always trigger builds. In last couple of months we updated software packages on the build servers which could have introduced this issue.

What makes this weird in our case is that we cannot reproduce this on our dev machines - when we build the same codebase with dotnet publish we get a properly functioning package without the references above - this issue is reproduced with builds from our build server.

While investigating this with the process running in Windbg, I noticed a reference to System.Text.Encoding.Extensions.Reference1 in the output from !dso which led me to the .deps.json file and it's list of dependencies. I noticed the following dependencies (these are not added on builds produced on my dev machine):

          "System.Text.Encoding.Extensions.Reference1": "4.0.11.0",
          "System.Collections.Reference1": "4.0.11.0",
          "System.Net.Primitives.Reference1": "4.0.11.0",
          "System.Linq.Expressions.Reference1": "4.1.2.0",
          "System.Reflection.Reference1": "4.1.2.0",
          "System.IO.Reference1": "4.1.2.0",
          "System.Diagnostics.Debug.Reference1": "4.0.11.0",
          "System.Globalization.Reference1": "4.0.11.0",
          "System.Runtime.Extensions.Reference1": "4.1.2.0",
          "System.Runtime.InteropServices.Reference1": "4.1.2.0",
          "System.Threading.Tasks.Reference1": "4.0.11.0",
          "System.Linq.Reference1": "4.1.2.0",
          "System.Collections.Concurrent.Reference1": "4.0.11.0",
          "System.Dynamic.Runtime.Reference1": "4.0.11.0",
          "System.Threading.Reference1": "4.0.11.0",
          "System.Text.RegularExpressions.Reference1": "4.1.1.0",
          "System.Reflection.Extensions.Reference1": "4.0.1.0",
          "System.Net.Http.Reference": "4.2.0.0",
          "System.IO.FileSystem.Reference1": "4.0.3.0",
          "System.IO.FileSystem.Primitives.Reference1": "4.0.3.0",
          "System.Runtime.Serialization.Primitives.Reference1": "4.2.0.0",

Removing allows the host process to start. I'm still trying to figure out what is causing these dependencies to be included.

[muratg]

@georgevella interesting. cc @eerhardt for the *.Reference1 lines in the deps file.

(Also, @georgevella this bug is closed, so I recommend filing another one.)

[drauch]

Please reopen this one, this bug is not resolved. When we fixate it to SDK 2.1.2xx it works, starting with .NET Core SDK 2.1.400 it doesn't work. This is a major issue for us, as we currently cannot update to ASP.NET Core 2.x.

[pranavkm]

@drauch can you open a new issue?

[pranavkm]

If you continue seeing this issue, here are some possible workarounds:

a) Consider upgrading to ASP.NET Core 2.0 or later. The issue is resolved in versions later than v1.x. b) Modify your application startup to avoid using the code path that triggers this issue. Here's what it would look like:

public void ConfigureServices(IServiceCollection services)
{
    ...

    var manager = new ApplicationPartManager();
    var assemblies = new[] { typeof(MyMainApp).Assembly, typeof(MyClassLibrary).Assembly };

    foreach (var assembly in assemblies)
    {
        manager.ApplicationParts.Add(new AssemblyPart(assembly));
    }

    services.AddSingleton(manager);
    services.AddMvc();
}

c) Pinning the SDK to an earlier version using global.json (See https://github.com/aspnet/Home/issues/3132#issuecomment-388102009)

If you need further help, please file an issue in https://github.com/aspnet/Mvc.