Aspnetcore: Dotnet core 2.1 rc-1 won't load projects targeting net461
_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
All 47 comments
_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
on 9 May 2018
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.
livarcocc
on 9 May 2018
What does your full csproj look like?
Tratcher
on 9 May 2018
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?
pranavkm
on 9 May 2018
@dloukola Is this a mixture of 1.x and 2.0.x stuff? Can you paste see a .csproj file?
muratg
on 9 May 2018
@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
muratg
on 9 May 2018
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>
dloukola
on 10 May 2018
The csproj looks fine.
Can you include the full exception stack trace please?
Tratcher
on 10 May 2018
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)
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.
dloukola
on 10 May 2018
@pranavkm can you take a look?
Tratcher
on 10 May 2018
Could you also share the deps file - bin\Debugnet461\win7-x64\WebApplication.deps.json?
pranavkm
on 10 May 2018
Deps file content: https://gist.github.com/pranavkm/fec9097812a9ba42d71942bd25023bc1
dloukola
on 10 May 2018
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:
```C#
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?
pranavkm
on 10 May 2018
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.
dloukola
on 10 May 2018
@dsplaisted can you answer @pranavkm's question about the reference libraries in the deps.json?
livarcocc
on 10 May 2018
@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.
livarcocc
on 10 May 2018
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
on 10 May 2018
Sorry, I take that back. I tried one more place and it worked!!
Thanks everybody!
dloukola
on 10 May 2018
@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.
dsplaisted
on 10 May 2018
@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.
pranavkm
on 11 May 2018
@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?
dsplaisted
on 11 May 2018
@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.
pranavkm
on 15 May 2018
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
robertmuehsig
on 25 May 2018
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.
shadowmint
on 1 Jun 2018
This is absolute dogshit. Installing a new SDK (2.1) should not break an old one.
mattfrear
on 5 Jun 2018
@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?
davidfowl
on 5 Jun 2018
@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.
mattfrear
on 5 Jun 2018
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 😢
spottedmahn
on 6 Jun 2018
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?
davidfowl
on 6 Jun 2018
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.
spottedmahn
on 6 Jun 2018
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!
ramandeep-singh-1983
on 15 Jun 2018
Everyone should check out @pranavkm answers of May 10
They're a LIFE SAVER
WouterVanherck
on 28 Jun 2018
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!
k7hpn
on 28 Jun 2018
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.
dsplaisted
on 31 Jul 2018
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?
johndoryforglory
on 1 Aug 2018
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
pranavkm
on 1 Aug 2018
@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
fschmied
on 16 Aug 2018
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 !!!
pspkshah
on 20 Aug 2018
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.
msgallagher
on 20 Aug 2018
@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
on 20 Aug 2018
@msgallagher I will check your Repro solution, and confirm on the same shortly.
pspkshah
on 20 Aug 2018
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.
georgevella
on 24 Aug 2018
@georgevella interesting. cc @eerhardt for the *.Reference1 lines in the deps file.
(Also, @georgevella this bug is closed, so I recommend filing another one.)
muratg
on 24 Aug 2018
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.
drauch
on 4 Sep 2018
@drauch can you open a new issue?
pranavkm
on 4 Sep 2018
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:
```C#
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.
pranavkm
on 4 Sep 2018
Related issues
rbanks54
·
3Comments
snebjorn
·
3Comments
rynowak
·
3Comments
Kevenvz
·
3Comments
BrennanConroy
·
3Comments
Most helpful comment
This is absolute dogshit. Installing a new SDK (2.1) should not break an old one.