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

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

Closed
livarcocc opened this issue May 9, 2018 · 47 comments

Comments

Projects
None yet
@livarcocc
Copy link

commented May 9, 2018

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):
image

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

This comment has been minimized.

Copy link
Author

commented May 9, 2018

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

This comment has been minimized.

Copy link
Author

commented May 9, 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.

@Tratcher

This comment has been minimized.

Copy link
Member

commented May 9, 2018

What does your full csproj look like?

@pranavkm

This comment has been minimized.

Copy link
Member

commented May 9, 2018

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

@muratg

This comment has been minimized.

Copy link
Contributor

commented May 9, 2018

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

@muratg

This comment has been minimized.

Copy link
Contributor

commented May 9, 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

@dloukola

This comment has been minimized.

Copy link

commented May 10, 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>
@Tratcher

This comment has been minimized.

Copy link
Member

commented May 10, 2018

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

@dloukola

This comment has been minimized.

Copy link

commented May 10, 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)
@dloukola

This comment has been minimized.

Copy link

commented May 10, 2018

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.

@pranavkm

This comment has been minimized.

Copy link
Member

commented May 10, 2018

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

@dloukola

This comment has been minimized.

Copy link

commented May 10, 2018

@pranavkm

This comment has been minimized.

Copy link
Member

commented May 10, 2018

Yup, this is a dup of aspnet/Mvc#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 aspnet/Mvc@3f2fd6f 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

This comment has been minimized.

Copy link

commented May 10, 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.

@livarcocc

This comment has been minimized.

Copy link
Author

commented May 10, 2018

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

@livarcocc

This comment has been minimized.

Copy link
Author

commented May 10, 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.

@dloukola

This comment has been minimized.

Copy link

commented May 10, 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

This comment has been minimized.

Copy link

commented May 10, 2018

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

@dsplaisted

This comment has been minimized.

Copy link

commented May 10, 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.

@pranavkm

This comment has been minimized.

Copy link
Member

commented May 10, 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.

@dsplaisted

This comment has been minimized.

Copy link

commented May 10, 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.

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?

@muratg muratg added this to the Discussions milestone May 11, 2018

@pranavkm

This comment has been minimized.

Copy link
Member

commented May 15, 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.

@robertmuehsig

This comment has been minimized.

Copy link

commented May 25, 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

@shadowmint

This comment has been minimized.

Copy link

commented Jun 1, 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.

@mattfrear

This comment has been minimized.

Copy link

commented Jun 5, 2018

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

@mattfrear

This comment has been minimized.

Copy link

commented Jun 5, 2018

@davidfowl I came here after raising a separate issue (Azure/service-fabric-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

This comment has been minimized.

Copy link

commented Jun 6, 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 😢

@davidfowl

This comment has been minimized.

Copy link
Member

commented Jun 6, 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?

@spottedmahn

This comment has been minimized.

Copy link

commented Jun 6, 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.

@ramandeep-singh-1983

This comment has been minimized.

Copy link

commented Jun 15, 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!

@WouterVanherck

This comment has been minimized.

Copy link

commented Jun 28, 2018

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

@haraldnagel

This comment has been minimized.

Copy link

commented Jun 28, 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!

@dsplaisted

This comment has been minimized.

Copy link

commented Jul 31, 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.

@pranavkm pranavkm closed this Jul 31, 2018

@pranavkm pranavkm added the bug label Jul 31, 2018

@pranavkm pranavkm removed this from the Discussions milestone Jul 31, 2018

@johndoryforglory

This comment has been minimized.

Copy link

commented Aug 1, 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?

@pranavkm

This comment has been minimized.

Copy link
Member

commented Aug 1, 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 - #3132 (comment). 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

This comment has been minimized.

Copy link

commented Aug 16, 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

@pspkshah

This comment has been minimized.

Copy link

commented Aug 20, 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 !!!

@msgallagher

This comment has been minimized.

Copy link

commented Aug 20, 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.

@pspkshah

This comment has been minimized.

Copy link

commented Aug 20, 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

This comment has been minimized.

Copy link

commented Aug 20, 2018

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

@georgevella

This comment has been minimized.

Copy link

commented Aug 24, 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.

@muratg

This comment has been minimized.

Copy link
Contributor

commented Aug 24, 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.)

@drauch

This comment has been minimized.

Copy link

commented Sep 4, 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.

@pranavkm

This comment has been minimized.

Copy link
Member

commented Sep 4, 2018

@drauch can you open a new issue?

@pranavkm

This comment has been minimized.

Copy link
Member

commented Sep 4, 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:

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 #3132 (comment))

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

@aspnet aspnet locked and limited conversation to collaborators Sep 4, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.