.Net Core 2.0 SDK causes ASP.Net 1.1 Web App with project references to break

[jeffpapp]

After I installed the .Net Core 2.0 SDK I started getting an InvalidOperationException: Can not find assembly file Microsoft.CSharp.dll at 'C:\Projects\Temp\VS2017Issue\WebApplication1\bin\Debug\net462\refs,C:\Projects\Temp\VS2017Issue\WebApplication1\bin\Debug\net462\ error at runtime on a web application that references a class library project.

If I remove the class library project reference then the runtime error goes away.

Falling back to the .Net Core 1.0.4 SDK (uninstall 2.0 or use global.json to target 1.0.4) also fixes the issue.

I have a sample app that reproduces the issue at https://github.com/squareitechnologies/VS2017Issue

[TomGroeneboer]

Even more fun, if you try to target the ClassLibrary on netstandard1.6, you will see

Error The version of Microsoft.NET.Sdk used by this project is insufficient to support references to libraries targeting .NET Standard 1.5 or higher. Please install version 2.0 or higher of the .NET Core SDK. C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\Microsoft.NET.Build.Extensions.NETFramework.targets 57

Which is to be "fixed" by setting <DependsOnNETStandard>netstandard1.6</DependsOnNETStandard> in the PropertyGroup in your .csproj file.

Might be another issue, might not be, but I saw it after I "fixed" (a.k.a. worked around) the Microsoft.CSharp.dll error.

[dasMulli]

@TomGroeneboer did you install the 2.0.0 SDK? (https://www.microsoft.com/net/download/core).

[TomGroeneboer]

@dasMulli Yes I did.
dotnet --info output:

.NET Command Line Tools (2.0.0)

Product Information:
 Version:            2.0.0
 Commit SHA-1 hash:  cdcd1928c9

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.15063
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.0.0\

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.0
  Build    : e8b8861ac7faf042c87a5c2f9f2d04c98b69f28d

[jeffpapp]

@TomGroeneboer and @dasMulli
I also get the same Error The version of Microsoft.NET.Sdk used by this project is insufficient to support references to libraries targeting .NET Standard 1.5 or higher. Please install version 2.0 or higher of the .NET Core SDK. error if I add a global.json to use the 1.1.0 SDK when I build in VS2017.3. Building using dotnet build works correctly in that case.

Did you add <DependsOnNETStandard>netstandard1.6</DependsOnNETStandard> to the class library project or to the project that references the the class library?

That might at least get me in a mode where I can build and run in VS2017.3

[TomGroeneboer]

@jeffpapp Oh, yeah right, you're targeting netstandard1.5 :) I've added the DependsOnNETStandard in the web project. Not sure if you need to put in netstandard1.5 as value, since your class library targets that.

[dasMulli]

AFAIK the error is expected for the 1.* SDKs since they really don't have support to add the required compatibility assemblies to netfx projects that target .net standard versions. (Note the two lines for .net framework support in the table at https://docs.microsoft.com/en-us/dotnet/standard/net-standard)

However, that is a different issue than the missing Microsoft.CSharp.dll.

[TomGroeneboer]

@dasMulli True, they do not have to support the scenario we have. However, the 2.0 SDK does and that is indeed a bug. My 'fix' is just a workaround until MS fixes the issue.

[dasMulli]

I believe this may be an issue of new logic to generate the deps.json file requiring a new version of Microsoft.Extension.DependencyModel that include dotnet/core-setup@3574984 (or some other change).

Adding a reference to the new NuGet package for the ASP.NET Core 1.1 app resolves the issue in @jeffpapp's example project on my machine:

<PackageReference Include="Microsoft.Extensions.DependencyModel" Version="2.0.0" />

cc @eerhardt

[jeffpapp]

@dasMulli That worked for me too in both my sample and real apps.

So this is caused by the 2.0 tooling creating a different deps.json file than what the 1.1 runtime was expecting? And then manually adding that NuGet package updates how the 1.1 runtime deals with the new deps.json file?

I'm trying to understand what's happening so I can decide if I want to use the upgraded package in our production 1.1 app, or maybe wait for a fix of some kind to the 2.0 tooling if that would be possible.

[dasMulli]

I agree with what @natemcmaster wrote:

this is the piece I find most concerning. […] Just installing the new version shouldn't have broken things.

But this is exactly what happened. As long as there is no breaking API change using the 2.0.0 dependency model with 1.* asp.net core libraries I think you should be fine but I can't tell.

[eerhardt]

I quickly looked into this issue and here is my analysis:

In the 2.0 tooling, we made a change to copy reference assemblies into the 'refs' folder even during dotnet build and dotnet run. In 1.x, the 'refs' folder was only populated on dotnet publish.
The reasoning for this change was because certain reference assemblies are not resolvable at runtime. Specifically the reference assemblies necessary for netstandard2.0 support, but that was just a special case of any reference with "private/copylocal=false".

The place this broke was an assumption that code in DependencyModel v1.x makes

            var refsPath = Path.Combine(_basePath, RefsDirectoryName);
            var isPublished = _fileSystem.Directory.Exists(refsPath);
...
                    // throw in case when we are published app and nothing found
                    // because we cannot rely on nuget package cache in this case
                    if (isPublished)
                    {
                    throw new InvalidOperationException(
                        $"Can not find assembly file {assemblyFile} at '{string.Join(",", directories)}'");
                }

It assumes that if a refs directory exists, then the app must be published. And if it is published, it shouldn't let any other "resolver" look for the assembly.

This assumption was changed in DependencyModel v2.0, which is what @dasMulli calls out above. So referencing 2.0 DependencyModel is a valid workaround for this issue. Or continue using the 1.x SDK in a global.json will also unblock you, like you did in the repro repo: https://github.com/squareitechnologies/VS2017Issue.

[jeffpapp]

This assumption was changed in DependencyModel v2.0, which is what @dasMulli calls out above. So referencing 2.0 DependencyModel is a valid workaround for this issue. Or continue using the 1.x SDK in a global.json will also unblock you, like you did in the repro repo: https://github.com/squareitechnologies/VS2017Issue.

Are there any downsides with using 2.0 DependencyModel with other 1.1 packages? Or should everything work correctly with the newer DependencyModel?

[dasMulli]

This may be a candidate for an LTS fix for Microsoft.Extensions.DependencyModel since pinning the SDK to 1.1.0 might not work for users with a setup referencing netstandard libraries from netfx that the 1.1.0 SDK no longer allows. Updating to the 2.0.0 SDK then allows the projects to build again but fail at runtime, so LTS is effectively broken in that scenario if you want to be "LTS-only" (no 2.* packages).

This is not a requirement for us since we plan to update everything to 2.0 asap, but it would be interesting to hear what other users want/need.

[neman]

I managed my project to build with SDK 1.0.4 after commenting this out in file Microsoft.NET.Build.Extensions.NETFrameworks.targets

<!-- prevent using an older SDK version with NETStandard2.0 references --><!--
    <PropertyGroup>
      <_UsingOldSDK Condition="'$(UsingMicrosoftNETSdk)' != 'true' AND ('$(TargetFramework)' != '' OR '$(TargetFrameworks)' != '')">true</_UsingOldSDK>
    </PropertyGroup>
    <NETBuildExtensionsError Condition="'$(DependsOnNETStandard)' == 'true' AND '$(NETStandardInbox)' != 'true' AND '$(_UsingOldSDK)' == 'true'" ResourceName="UnsupportedSDKVersionForNetStandard20"/>-->

although I do not think it is a smart move.

UPDATE:
Silly me, I just added <DependsOnNETStandard>netstandard1.6</DependsOnNETStandard> as @TomGroeneboer wrote. Works perfect for me.

[xenry]

I started hitting the same issue as @TomGroeneboer (and as it seems many others) after updating to 15.3 and installing the .net core 2.0 sdk:
The version of Microsoft.NET.Sdk used by this project is insufficient to support references to libraries targeting .NET Standard 1.5 or higher. Please install version 2.0 or higher of the .NET Core SDK
Now I have done everything short of downgrading VS to 15.2 - uninstalled all net core sdks that I had and installed again only sdk 1.0.4, added the <DependsOnNETStandard>true</DependsOnNETStandard> property, but still I cannot get rid of that error. I am trying to build a simple net462 project that references netstandard 1.5 project.
What is the suggested recovery story here?

[eerhardt]

/cc @nguerrera @dsplaisted - for help with the

The version of Microsoft.NET.Sdk used by this project is insufficient to support references to libraries targeting .NET Standard 1.5 or higher. Please install version 2.0 or higher of the .NET Core SDK

error.

@TomGroeneboer and @xenry - maybe a separate issue should be opened for this, as it is a separate problem than what this issue was logged for.

[neman]

@xenry try to add <DependsOnNETStandard>netstandard1.6</DependsOnNETStandard> instead of <DependsOnNETStandard>true</DependsOnNETStandard>

[nguerrera]

The version of Microsoft.NET.Sdk used by this project is insufficient to support references to libraries targeting .NET Standard 1.5 or higher. Please install version 2.0 or higher of the .NET Core SDK
maybe a separate issue should be opened for this, as it is a separate problem than what this issue was logged for.

cc @ericstj

There is https://developercommunity.visualstudio.com/content/problem/93342/cant-downgrade-to-lower-net-core-sdk.html, but no issue on GitHub yet.

[nguerrera]

Let's discuss SDK 1.x vs netstandard1.5/1.6 refs at #1527 or on the developercommunity thread and stick to the original issue of .NET Core 2.0 SDK causing runtime failure in 1.1 app here.

[nguerrera]

Getting back to the original issue, the options I see are:

1. Ship a 1.x patch to DependencyModel and recommend that use that
2. Bless using DependencyModel 2.0 from 1.1 apps as LTS and recommend that as the workaround.
3. Change things in 2.0.x so that this only applies when the app is 2.0+ or if the app references DependencyModel 2.0+

[dasMulli]

Similar issue: #1524, though not related to netfx

[eerhardt]

I'm not sure

3. Change things in 2.0.x so that this only applies when the app is 2.0+ or if the app references DependencyModel 2.0

will work correctly. @nguerrera (or @ericstj and @dsplaisted) would know more than me as I think this change came in while I was out.

Even netstandard1.5 and netstandard1.6 references now use facade assemblies. If that's true, then these facade assemblies will need to be copied to the refs folder even during dotnet build/run time, so they can be resolved while running the app. See #1387.

#1272 made it so "Copy any Reference that can't be resolved at runtime to the build output "refs" folder.". I think these netstandard1.5 and netstandard1.6 facades fall into that category.

My opinion is we should do a hybrid of (2) and (1) above. I'm not aware of any reason the 2.0 DependencyModel won't work with a 1.1 app. So for now, I recommend people running into this issue either use the 1.x SDK, or upgrade DependencyModel to 2.0 (or upgrade to netcoreapp2.0 completely if they want/can). But I also think we should backport the change into 1.1.x of DependencyModel.

I've logged https://github.com/dotnet/core-setup/issues/3081 to make the DependenyModel change.

[livarcocc]

I am going to close this issue since it seems the suggested approaches are all around DependencyModel:

1. Using the 2.0 DependencyModel in 1.1 apps.
2. Porting the fix from the 2.0 DependencyModel into the 1.1 DependencyModel, which is tracked by the issue referenced above by Eric.

If I misunderstood something, please, comment and I can re-activate this issue.

[multiarc]

The issue is still persists (appeared again?) for both .NET Core SDK 1.1.8 & 2.1.101

Target startup project to net4xx only and reference netstandard1.6 library having no netxxx targets (which is library dependent, I can try to provide isolated example).

Whole build process for a project is broken at this point, and project mentioned in error has nothing to do with real issue.

Sometimes error(s) appears in cases where is no real issue with project mentioned in error text, which is misleading and cause issues with future investigation.

If you force project to have reference <DependsOnNETStandard>netstandard1.6</DependsOnNETStandard>
facade libraries will have manifests to reference netstandard2.0 for some reason, whereas no library referencing netstandard2.0 exists.

Is it a hard override for updated SDKs (seems both 1.1 and 2.1) to force facade libraries to reference netstandard2.0?

The further you get, the harder the going.

[dsplaisted]

@multiarc Since this issue is closed, and I'm not sure whether or not you're encountering the same root issue anyway, can you file a separate bug, and try to include repro steps?

Thanks

[drauch]

If someone else runs into this problem...we ran into it after updating VS to 15.8.

Updating Microsoft.AspNetCore to >= 1.1.7 and Microsoft.AspNetCore.Mvc to >= 1.1.8 fixed the problem on our side.