Sdk: netcoreapp2.0 cannot reference netstandard2.0 in VS2017 preview

[srivatsn]

_From @karelz on May 16, 2017 12:58_

_From @danwalmsley on May 4, 2017 17:27_

If I build from command line it works.

But from latest vs2017 preview I get:
...project.... targets '.NETStandard,Version=v2.0'. It cannot be referenced by a project that targets '.NETCoreApp,Version=v2.0'.

Is the a workaround for now?

_Copied from original issue: dotnet/coreclr#11391_

_Copied from original issue: dotnet/project-system#2192_

[srivatsn]

_From @karelz on May 16, 2017 12:58_

_From @watashiSHUN on May 4, 2017 18:46_

when you say you can build it on the command line, you mean you are using dotnet cli? ( in my case running dotnet run with version 2.0.0-preview2-005905 on this project is successful)

But I also got a similar error while trying to build .NetStandard2.0 in VS2017, please see this stackoverflow question...

[srivatsn]

_From @karelz on May 16, 2017 12:58_

_From @danmosemsft on May 8, 2017 4:9_

@terrajobst is it expected to work in this version?

[srivatsn]

_From @karelz on May 16, 2017 12:58_

_From @terrajobst on May 8, 2017 18:6_

Which version of VS 2017 are you using? Help | About | Copy Info. This will work with the build we give out at Build.

[srivatsn]

_From @karelz on May 16, 2017 12:58_

BTW: It doesn't look like it belongs into CoreCLR repo ...

cc @weshaggard @ericstj

[srivatsn]

_From @karelz on May 16, 2017 12:58_

_From @NinoFloris on May 11, 2017 19:32_

It's the same for omnisharp

        Update project: Project
[fail]: OmniSharp.MSBuild.ProjectFile.ProjectFileInfo
        Project '/Users/nfloris/Projects/Project/Project.csproj' targets '.NETStandard,Version=v2.0'. It cannot be referenced by a project that targets '.NETCoreApp,Version=v2.0'.

it does compile, restore, test etc though

[srivatsn]

_From @karelz on May 16, 2017 12:58_

_From @ericstj on May 11, 2017 19:37_

Agree with @terrajobst, problem appears to be the VS setup.
Issues on project system should be filed in https://github.com/dotnet/project-system.

[srivatsn]

_From @karelz on May 16, 2017 12:58_

_From @NinoFloris on May 11, 2017 20:8_

Doesn't VS also use msbuild?

[srivatsn]

_From @karelz on May 16, 2017 12:58_

_From @karldodd on May 16, 2017 7:54_

Same problem for me here. I am using OmniSharp in VSCode.

I guess anyone in charge can move this issue to https://github.com/dotnet/project-system ?

[terrajobst]

@danwalmsley can you share the VS version you've been using? This works assuming:

• You're running Visual Studio 2017 version 15.3 Preview
• The latest .NET Core 2.0 preview

[Joe4evr]

Having the same issue on Update 3 RTM, and I've never installed the U3 previews.
To be honest, if this has been known since May, then it's a very egregious shortcoming and should've been a critical priority before pushing out a release, if you ask me. =/

Whoops, looks like this is solved by setting the sdk version in global.json to 2.0.0. 😅

[Ghostbird]

Maybe a tad off-topic, but when I searched about this problem I ended up here a lot.
In my case I got this message after I had installed the 2.0 SDK. It turned out I had forgotten to uninstall the old dotnet 1.6 SDK. When I removed the old SDK, the problem disappeared.

This was actually on a Debian machine using Visual Studio Code, so I'm not sure the underlying reason is exactly the same.

[mcowart123]

Same issue here. Running VS 2017 15.3 with 2.0 SDK installed, and it refuses to install a netstandard 2.0 package in a netcoreapp2.0 console app. Going to try uninstalling all the previous .net core SDks and see if that fixes it.

EDIT: I fixed this by some combination of the following:

1. VS2017 15.3.1 update just came out
2. Forcing my nuget install to 4.3.0 (nuget update -self was only going to 4.1)
3. Modifying my .nuspec to add
   <group targetFramework="netstandard2.0"><dependency id="NETStandard.Library" version="2.0" />[OTHER DEPENDENCIES]...</group>

[sandersaares]

This occurs in Visual Studio Team Services build agents. It appears that the NuGet task there uses NuGet 4.0.0, which has this issue. Using NuGet 4.3.0 fixes it.

Ref: https://github.com/Microsoft/vsts-tasks/issues/5065

[chuckconway]

I fixed it by changing my target in the csproj file to netstandard2.0
<TargetFramework>netstandard2.0</TargetFramework>

[nloding]

This issue was driving me nuts on MacOS after updating to .NET Core 2.0 and ASP.NET Core 2.0 with VSCode. Turns out I had a global.json with an old sdk value listed within one of the projects, and that cascaded down through the project loading, even though the root global.json had sdk: "2.0.0". If you are still stuck, double check your global.json files!

[MovGP0]

dotnet restore, dotnet build and dotnet run work successfully.

dotnet publish causes the following error:

C:\Program Files\dotnet\sdk\1.0.4\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Sdk.Common.targets(73,5): error : Project 'C:\Users\…\XXX.csproj' targets '.NETStandard,Version=v2.0'. It cannot be referenced by a project that targets '.NETCoreApp,Version=v2.0'. [C:\Users\…\XXX.csproj]

The Project looks like the following:

<Project ToolsVersion="15.0" Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>
    <IsPackable>false</IsPackable>
    <TypeScriptToolsVersion>Latest</TypeScriptToolsVersion>
    <AssemblyName>Foobar</AssemblyName>
  </PropertyGroup>

  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|AnyCPU'">
    <LangVersion>latest</LangVersion>
  </PropertyGroup>

  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
    <LangVersion>latest</LangVersion>
  </PropertyGroup>

  <ItemGroup>
    …
  </ItemGroup>
</Project>

The referenced project looks like:

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

  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <AssemblyName>Foobar.Api</AssemblyName>
    <RootNamespace>Foobar.Api</RootNamespace>
  </PropertyGroup>

  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
    <LangVersion>latest</LangVersion>
  </PropertyGroup>

  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|AnyCPU'">
    <LangVersion>latest</LangVersion>
  </PropertyGroup>

  <ItemGroup>
    …
  </ItemGroup>
</Project>

[danmosemsft]

@ericstj any idea about this one? Seems like it should certainly work.

[ericstj]

Yes it should work. It looks to me like something is still using the old version of NuGet dlls.

This explains that, emphasis added:

C:\Program Files\dotnetsdk\1.0.4\Sdks\Microsoft.NET.Sdkbuild\Microsoft.NET.Sdk.Common.targets(73,5): error : Project 'C:\Users\…XXX.csproj' targets '.NETStandard,Version=v2.0'. It cannot be referenced by a project that targets '.NETCoreApp,Version=v2.0'. [C:\Users\…XXX.csproj]

Figure out why you're using SDK 1.0.4 and you'll solve your problem. Things to check for: global.json in this project directory; missing x64 SDK for 2.0; /cc @eerhardt @nguerrera for any other suggestions.

[eerhardt]

If you are targeting netcoreapp2.0 or netstandard2.0, you need to be using the 2.0 SDK.

You can always check which SDK version is being used in a certain directory by executing dotnet --info from that directory.

[danmosemsft]

Thanks, I overlooked the version number in the error.

[MovGP0]

I found a solution, but you might not like it. Apparently the error is caused by an faulty installation of the .NET Core SDK. Reinstalling the SDK it did not help.

Reformatting the disk and setting up the system from scratch solved the problem for me.

There might be a more elegant solution to it, but I didn't wanted to waste too much time on it.

[livarcocc]

This works if you use at least a 2.0 SDK, like @eerhardt suggests above. Also, in VS, if you are targeting 2.0 but does not have an SDK that supports it, you get this error:

The current .NET SDK does not support targeting .NET Core 2.0.  Either target .NET Core 1.1 or lower, or use a version of the .NET SDK that supports .NET Core 2.0.

[itadapter]

Sorry but, still having issues and all Google links come here.

Using dotnet 2.1.3, VS2017 15.5.2;

Have a solution with both .NET and .Core projects (in the same solution). The build works fine in VS2017, however it does generate the same error when building either using MsBuild cli, or dotnet build cli.

UPDATE:
Looks like this is related:
https://blogs.msdn.microsoft.com/visualstudio/2010/12/21/incorrect-solution-build-ordering-when-using-msbuild-exe/
The project build order in solution is used to "link" when you build from command line, whereas we need just to specify the build order without any "linking"

[itadapter]

@itadapter @livarcocc @danmosemsft @KirillOsenkov
Related? msbuild/issues/1916
NuGet/Home/issues/4700
UPDATE, this issue arises from this:
If one specifies solution PROJECT BUILD ORDER via project dependencies then VS2017 "understands" that solution project dependency is not equal to assembly reference, whereas cli msbuild does not understand this.

Consequently, there is NO WAY to specify declarative build order. Here is a trick, add this to you CSPROJ:

<ItemGroup>
    <ProjectReference Include="..\runtimes\netf\buildinfo\buildinfo.csproj">
      <ReferenceOutputAssembly>false</ReferenceOutputAssembly>
    </ProjectReference>
</ItemGroup>

What this does, it changes the build graph order, but does not reference the assembly. But this ploy still does not work, because now you have all project dependency in VS broken, it builds OK, but solution explorer shows "yellow warnings" on all projects because it thinks that you are linking to a missing assembly.

The question is: how does one properly specify the build order of projects? In my case I need to build one tool first and then use it in pre-build step before building other csproj.
The explicit project dep in solution causes msbuild to treat it as a linking/referencing command, which is questionable. There is gotta be a flag for specific build order, and the technique with ReferenceOutputAssembly>false does not cut it either as it breaks VS flow.

Thoughts?

[danmosemsft]

I would open a new issue in the MSBuild repo.

[rainersigwald]

No need for a new issue, command-line MSBuild confusing solution build dependencies with project references is https://github.com/Microsoft/msbuild/issues/2661. There are a couple of other workarounds mentioned there, and we plan to fix it for the next release.

[SayusiAndo]

Hi All,

Any update on this?

I have a Durable Functions project, which references netstandard2.0. Other class library projects point to netcoreapp2 and I got the same error.

Durable Functions project:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <AzureFunctionsVersion>v2</AzureFunctionsVersion>
  </PropertyGroup>

Class library project:

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

  <PropertyGroup>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <AssemblyName>DigitalLibrary.MasterData.Api</AssemblyName>
    <RootNamespace>DigitalLibrary.MasterData.Api</RootNamespace>
  </PropertyGroup>
</Project>

Error:
Project '..\.csproj' targets 'netcoreapp2.0'. It cannot be referenced by a project that targets '.NETStandard,Version=v2.0'. (1, 1)

Environment:

.NET Command Line Tools (2.1.4)

Product Information:
 Version:            2.1.4
 Commit SHA-1 hash:  5e8add2190

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

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.5
  Build    : 17373eb129b3b05aa18ece963f8795d65ef8ea54

[weshaggard]

@SayusiAndo that error is correct and by design. You cannot reference a class library targeting .NET Core 2.0 from a .NET Standard 2.0 project, you can do the reverse though.