sdk: dotnet restore unable to resolve .NET Framework libraries (4.5.2, 4.6.2)

PLEASE FIX IT ASAP!

I cannot integrate any code in my ASP.Net Core (.Net Framework) application.

All work is stopped!

The nuget implementation inside of CLI in our preview2 tooling, as well as the CLI itself, does not know how to reason about csproj files directly. In fact, the csproj/xproj concepts get layerd on top of project.json. This discrepancy is representative of why the team is now focused on Changes to the project model.

At the moment we have two options for interacting with these sorts of mixed models. First, we can use Visual Studio which understands csproj and xproj. Though I haven’t tried myself, I expect this should scale to building the project at the command line using MSBuild. The second approach is to build the csproj-based binaries and wrap them in NuGet packages, referencing those nuget packages from project.json.

Unfortunately, the current iteration of CLI is not capable of building .csproj projects, so a completely CLI-based approach is not available [yet].

It seems that also with the final release of ASP.NET Core 1.0 the situation remains unchanged. I’m still able to create a “mixed” solution (with xproj and csproj), the solution builds in VS but not via MSBUILD.

That is kind of odd: if this was not meant to be allowed, why is it still possible in VS and why in all pics/posts related to .Net Core it is actually highlighted that the mixure is viable

I was hoping in a resolution for this problem with the final release but still nothing changed. There are a lot of people interested in using ASP.NET Core 1.0 with the standard .NET Framework and not the Core libraries. Potentially this problem will grow exponentially once users not involved from the beginning (project k, vnext, …) will take this behaviour for granted.

It is ok for me to tag it as a Nuget issue, but maybe it would be easier and cleaner to split ASP.NET Core 1.0 projects per Framework (as the rest is), so an ASP.NET Core 1.0 app built on top of the regular .NET Framework should come with a “standard” csproj whereas the one build with .NET Core with the xproj. That will probably resolve the majority of problems of finding the proper dependencies to load.

I have the following 3 projects:

1. Class Library (.Net Framework 4.5.2), called «CL1»
2. ASP.NET Core Web Application (.Net Framework), called «AspNetCoreNetFrameworkDemo», references «CL1»
3. Class Library (.Net Core), called «AspNetCoreFrameworkDemoTest», for unit testing, references «AspNetCoreNetFrameworkDemo»

The reference to «AspNetCoreNetFrameworkDemo» is shown in the test project, which in turn references «CL1».

NuGet restore fails with the error: «Unable to resolve CL1 for .NETFramework,Version=v4.5.2»

I use Nuget 3.4.4 how the following log shows:

This is project.json (test project, «AspNetCoreFrameworkDemoTest»):

Is there a solution or workaround for this issue? Michael

Workaround: Use a 3.5 (Beta) version of Nuget.exe and run “nuget restore” instead of “dotnet restore”.

Credit to @emgarten for suggesting this.

I’m getting the same issue - .NET Core on .NET 4.6.1 referencing another project in the same solution (also targeted at .NET 4.6.1) outputs an error “unable to resolve… for .NETFramework, Version=v.4.6.1”

@timotyweis Where’s the duplicate issue? Should I track this one or the other one for updates?

The related issue is about a conflict between dependencies in csproj and xproj. But I am getting the same “Unable to resolve…” error for a class library with no dependencies.

I just had to do a dotnet clean before my dotnet restore.

I found a not so elegant workaround to get it to work on my CI builds I thought I would share while we wait for this issue to be resolved. The folder structure of my example project is as follows.

ClassLibrary1
--ClassLibrary1.csproj
src
--dncClassLibrary1
----dncClassLibrary1.xproj
----project.json
Solution.sln
global.json

The first thing to notice was that when we restore packages in VS for an xproj it executes the following C:\Program Files\dotnet\dotnet.exe restore "[SOLUTIONDIRECTORY]\.vs\restore.dg"

The contents of restore.dg are

#:[SOLUTIONDIRECTORY]\src\dncClassLibrary1\dncClassLibrary1.xproj
[SOLUTIONDIRECTORY]\src\dncClassLibrary1\dncClassLibrary1.xproj|[SOLUTIONDIRECTORY]\ClassLibrary1\ClassLibrary1.csproj

That however only generates a project.lock.json, and if we try to dotnet build we get the error Lock file Microsoft.DotNet.ProjectModel.Graph.LockFile contains msbuild projects but there is no export file

I figure the export file is the project.fragment.lock.json that VS generates. I don’t really know how VS generates it. But, as long as you keep your project.fragment.lock.json in your repository, that shouldn’t be an issue. The restore.dg is a bit trickier since the paths in it are absolute. The best way to handle it for me was to put a restore.dg in each dotnet core project’s directory. It should have the section of .vs/restore.dg pertaining to that project. You should also make the paths relative. So, for my example, the restore.dg file for dncClassLibrary1.xproj would be in /src/dncClassLibrary1 and its content would be

#:dncClassLibrary1.xproj
dncClassLibrary1.xproj|..\..\ClassLibrary1\ClassLibrary1.csproj

In your build server just execute dotnet restore restore.dg in every dot net core project’s folder. and then dotnet build

edit: A bit of a fix is required if you want to keep building project.json files but have installed VS2017 or an SDK that supports csproj only (I think 1.1.0+). In that case you need to also include a global.json file in your project folder specifying the 1.0.0-preview2-3156 sdk.

@timotyweis Please re-open the issue and I will provide a sample to reproduce it.

Please do ask more questions so we can be sure to get the story documented well.

You get it right. But it could be very nice to publish all important information at once: error confirmed but VS 2015 support closed. Note: support is closed. Not issue. “wan’t fix” is real status of issue.

I’m getting this:

Lock file Microsoft.DotNet.ProjectModel.Graph.LockFile contains msbuild projects but there is no export file

When running dotnet build.

This is my version:

Microsoft .NET Core Shared Framework Host

Version : 1.1.0 Build : 928f77c4bc3f49d892459992fb6e1d5542cb5e86

@frourke I’ve tried your approach with Nuget 3.5 rc1, a pretty vanilla solution with one .NET Core WebApp and a ClassLibrary (.NET Framework). The restore command did indeed succeed, but the successive msbuild command fails.

@barynov Here you go

the benefits of .Net Core (new routing, DI, all that good stuff)

Just to clarify: those are features of the new ASP.NET Core framework, which happens to work in both .NET Framework and .NET Core.

@piotrpMSFT Could you help me and explain what is

preview3+ tooling and csproj

and how to install it on VS 2015 Update 3 ? I expect that you are talking about those new csproj that should replace xproj … But is it possible to get this tooling package now (and new csproj mvc project template to see how to use new csproj possibilities) ?

P.S. Am I correct that only tooling preview 2 currently is available for public (for Visual Studio 2015)… https://www.microsoft.com/net/core#windowsvs2015 ? If it is true, then I would like to understand your motivation to close the issue before package become available for download…

I removed all the project references and added them back again, and solved the problem.

Before this, I always removed all the .lock.json files and to do rebuild, or dotnet restore. Used nuget 3.5 and use nuget restore, it showed me that some legacy folder which I’ve changed a while ago, no idea where cached this information. So I removed all project references and added them back again, now finally can proceed my work.

@frourke MSBuild via command line (since is what will also be used by TeamCity afterwards)

@KonbOgonb solution worked for me too. Use NuGet.exe restore aPathToYour.sln (nuget 3.5 at least)

In my case solution with Nuget didn’t work until I manually provided path to solution file as an argument. Before it Nuget was trying to use project.json which resulted in “unable to resolve ”. Anyway hope this is going to be fixed and no workarounds will be needed.

@AaronRM I’m not able to get nuget restore to work, even using 3.5 beta 2. In the lastest NuGet blog post it says

“The .NET CLI 3.5 Beta 2 dotnet restore command also has been updated to this version.”

so I would think that means the RTM dotnet restore should work as well.

Running either still results in Unable to resolve 'My CSPROJ project' for '.NETFramework, Version=v4.6.1'