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

[timotyweis]

Steps to reproduce

In Visual Studio 2015

1. Create a new ASP.NET Core Web Application (.NET Framework)
2. Add a regular Class Library to the solution
3. Add a reference to the new class library (in my case .NET Framework 4.6.2) from the web app
4. run dotnet restore from the command line

   Expected behavior

dotnet restore completes without errors.

Actual behavior

The command terminates with the following error message:

Errors in C:\Users\xyz\Documents\Visual Studio 2015\Projects\WA-net\src\WebApplication1\project.json
    Unable to resolve 'ClassLibrary1' for '.NETFramework,Version=v4.5.2'.

In Visual Studio I can restore the packages and compile the application without any problem.

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.0-preview1-002702)

Product Information:
 Version:     1.0.0-preview1-002702
 Commit Sha:  6cde21225e

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.10240
 OS Platform: Windows
 RID:         win10-x64

[barynov]

I have the same problem for net451: it works in VS, but does not work with dotnet restore.

[tjrobinson]

I'm having the same problem. It works in Visual Studio but not when using the dotnet CLI. My class library targets .NET 4.6.1. Error: "Unable to resolve 'MyCompany.MyProject' for '.NETFramework,Version=v4.6.1'."

.NET Command Line Tools (1.0.0-preview1-002702)

Product Information:
 Version:     1.0.0-preview1-002702
 Commit Sha:  6cde21225e

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.10586
 OS Platform: Windows
 RID:         win10-x64

[tjrobinson]

@timotyweis Your "Actual behaviour" error message refers to '.NETFramework,Version=v4.5.2'. - shouldn't it be '.NETFramework,Version=v4.6.2'.?

[dmikov]

Identical, started with project 4.5.0, thought it might have been issue, build my project to 4.6.1 still cannot resolve that project when running dotnet restore for the target project.

[timotyweis]

@tjrobinson You're right, the message that I've posted is wrong (actually it was from a previous test with the v4.5.2 which is not working as well). I'm getting the same message with both Frameworks (v4.5.2 and v4.6.2)

[dmikov]

Guys, are your projects csproj based? Mine is. And you say classical so might be a duplicate of https://github.com/dotnet/cli/issues/3205

[tjrobinson]

Mine is csproj based, yes.

[barynov]

Still no workaround? This is a blocker for me that prevents to upgrade on RC2.

[timotyweis]

@dmikov yes a csproj based class library. The error seems different but at the end the problem may be really due to the fact that the mix of packages.congif and project.json dependency doesn't get resolved properly, preventing the correct inclusion of the "classical" libraries. What makes it really odd is that VS is capable of building the solution whatsoever, whereas via console (msbuild) this does not work.

[timotyweis]

Closed due to duplication

[barynov]

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.

[timotyweis]

@barynov If you prefer I may reopen the Issue and we'll wait for more detail.

[barynov]

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

[timotyweis]

@barynov Here you go

[timotyweis]

The Nuget issue to follow: NuGet/Home#2865

[andradf]

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.

[ghost]

PLEASE FIX IT ASAP!

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

All work is stopped!

[AaronRM]

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

Credit to @emgarten for suggesting this.

[timotyweis]

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.

[barynov]

I upgraded to the RTM version, but still have to use restore.dg workaround for TFS builds, because dotnet restore cannot not resolve desktop libraries.

[BrianVallelunga]

@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'

[BrianVallelunga]

Following up on my previous post, I found another workaround:

If you have a single .csproj project referenced in a project.json web app, nuget restore will work. If however, your .csproj project itself references other .csproj projects you'll need to directly reference all of those from your project.json web app as well. That will allow nuget restore to work.

[tomten]

This workaround seems to work for me:

1. Create the solution in the OP.
2. Change the file structure to the one suggested in this related issue comment by moving ClassLibrary1 into the src folder, making it a sibling of the web project folder. Update the .sln file accordingly.
3. Add a project.json to ClassLibrary1 referencing the net461 framework.
4. Remove the duplicate ClassLibrary1 project in the Visual Studio solution explorer.
5. Remove the ClassLibrary1 .csproj file. At this point, Visual Studio seems to have created an .xprojfile for ClassLibrary1.
6. dotnet restore in the solution folder now works.
7. dotnet build in the web project folder now works.
8. dotnet publish in the web project folder seems to work.

It may well be that this workaround breaks for any real-world solution though.

Essentially, it's the same workaround as in this related issue comment.

Other things to note:

• The nuget restore workaround doesn't work for me (or I don't understand how to run it). Running it in the solution directory made no difference to dotnet build or dotnet publish.
• I don't understand the restore.dg workaround.
• Using Visual Studio 2015 Update 3 with the ASP.NET tooling update.
• dotnet --info:

.NET Command Line Tools (1.0.0-preview2-003121)

Product Information: Version: 1.0.0-preview2-003121 Commit SHA-1 hash: 1e9d529bc5

Runtime Environment: OS Name: Windows OS Version: 6.3.9600 OS Platform: Windows RID: win81-x64

Is there still no other workaround less complicated than the ones in this issue?

[KonbOgonb]

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.

[blackhill]

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

[TheRealPiotrP]

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].

[DibranMulder]

I'm uncertain what approach I should take in case of building with Visual Studio Online. The documentation of ASP.net core documentation contains examples of dotnet restore. But this clearly doesn't work since I have multiple PCL's(csprojs) in my solution.

I expect this should scale to building the project at the command line using MSBuild.

Has anyone figured this out yet? Any examples would be very much appreciated. It should be easy to integrate MSBuild scripts into Visual Studio Online so that could solve my problem.

[frourke]

To get it working on VSO I have created a VM with Win 10 & Visual Studio 2015 Update 3. On VM, download and install the .Net Core tooling preview 2. Download CLI NuGet 3.5 beta (link above). Create an custom agent pool in VSO and download the agent to the VM. Configure the agent ( dont run from your download folder as you get all sorts of permission problems). Use c:\agent. Add an extra command line task, before your VS build task, to your build definition. tool : c:\nuget\nuget.exe , args : restore "$(build.sourcesDirectory)\xxx.sln" Set the build definition to use your custom agent. I hope i have not forgotten anything. I have multiple .csprojs referencing other csprojs and have no problems. Hope this helps.

[timotyweis]

@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.

[ChristianSacramento]

https://github.com/aspnet/Tooling/issues/741

[frourke]

@timotyweis, I will try find some time to test your simple solution in the next couple days. Are you using Visual Studio Build task or MSBuild task?

[timotyweis]

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

[frourke]

@timotyweis, I use the Visual Studio Build task, it may be worth trying that and if it works, compare the output of both tasks.

Here is the MSBuild command thats run for my Visual Studio task. The bolded args are the MSBuild args I added to the Visual Studio Task.

"C:\Program Files (x86)\MSBuild\14.0\bin\amd64\msbuild.exe" "c:\a\1\s\blabla.sln" /nologo /nr:false /dl:CentralLogger,"C:\agent\agent\tasks\VSBuild\1.0.40\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll"*ForwardingLogger,"C:\agent\agent\tasks\VSBuild\1.0.40\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll" /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="c:\a\1\a" /p:platform="any cpu" /p:configuration="release" /p:VisualStudioVersion="14.0" /p:_MSDeployUserAgent="VSTS_build_34_1108"

[timotyweis]

@frourke I'll give it a try as soon as possible. However, now I've also another issues, tests. Currently it seems impossible to have a test project set up to do some testing over my controllers (since the .NET core project can't reference the .NET framework) any solutions to this?

[keithn]

I'm trying to do this on Appveyor and just can't seem to get my project to build at all.

[keithn]

@piotrpMSFT is it still true we can't do CLI builds of dotnet core projects with mixed in .NET 4.6 projects? (using things like AppVeyor for continuous builds)

[matthieupetite]

Did you find a solution for that. We are trying to put CI on a .net mvc core project that reference csproj project for the business logic. Works fine on VS but we are facing issue on building the solution with TFS...

[IngbertPalm]

Have a look at Scott Hanselman's blog. Maybe this can help you.

[NBelham]

Just adding to the story so far... I have a simple AspNetCore 1.0 Web Project which has a single Class Library reference. This all builds fine under VS2015 Update 3. I wanted to setup CI setup with TFS Online but for the above the TFS build fails. If I remove the Web Project Ref to the Class Library, then the TFS Build completes fine. Adding it back and the TFS Build fails so this looks to be a TFS Tooling issue.

Can anyone advise what TFS Build options I need to set to make the TFS CI Build work?

[section]Starting: Run dotnet.exe

[command]dotnet.exe restore

Welcome to .NET Core!

Learn more about .NET Core @ https://aka.ms/dotnet-docs. Use dotnet --help to see available commands or go to https://aka.ms/dotnet-cli-docs.

Telemetry

The .NET Core tools collect usage data in order to improve your experience. The data is anonymous and does not include commandline arguments. The data is collected by Microsoft and shared with the community. You can opt out of telemetry by setting a DOTNET_CLI_TELEMETRY_OPTOUT environment variable to 1 using your favorite shell. You can read more about .NET Core tools telemetry @ https://aka.ms/dotnet-cli-telemetry.

Configuring...

A command is running to initially populate your local package cache, to improve restore speed and enable offline access. This command will take up to a minute to complete and will only happen once. Decompressing 100% 4726 ms 2016-10-17T13:23:05.7606879Z log : Restoring packages for C:\a\1\s\Mainline\src\MyNamespace.Web\project.json... Expanding 100% 19475 ms error: Unable to resolve 'MyNamespace.Common' for '.NETFramework,Version=v4.5.1'. log : Restoring packages for tool 'BundlerMinifier.Core' in C:\a\1\s\Mainline\src\MyNamespace.Web\project.json... log : Restoring packages for tool 'Microsoft.AspNetCore.Razor.Tools' in C:\a\1\s\Mainline\src\MyNamespace.Web\project.json... log : Restoring packages for tool 'Microsoft.AspNetCore.Server.IISIntegration.Tools' in C:\a\1\s\Mainline\src\MyNamespace.Web\project.json... log : Writing lock file to disk. Path: C:\a\1\s\Mainline\src\MyNamespace.Web\project.lock.json log : C:\a\1\s\Mainline\src\MyNamespace.Web\project.json log : Restore failed in 4208ms. Errors in C:\a\1\s\Mainline\src\MyNamespace.Web\project.json Unable to resolve 'MyNamespace.Common' for '.NETFramework,Version=v4.5.1'.

[error]Process completed with exit code 1.

[section]Finishing: Run dotnet

[keithn]

I got it working. I use appveyor and Git and I ended up scripting via powershell the whole build instead of letting appveyor work out how to build it. I use visual studio to do the build rather than msbuild. I use the beta version of nuget as mentioned . Using visual studio is the Key point as it seems to know how to restore .net for mixed enviroments.

the two sets are to get rid of appveyors enviroment variables which effect the build.

set Configuration= set Platform= call "\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" NuGetbeta3dot5.exe restore devenv MyProject.sln /build Debug or devenv MyProject.sln /build Release

then. I use webpack, so don't need to include it if you don't use it, appveyor is always a blank machine without webpack or bower so it has to be installed per build. Bower is needed for the dotnet publish,

cd src cd MyProject npm install -g webpack webpack npm install -g bower dotnet publish

then I found I needed to copy the project.json to the published directory

copy project.json .\bin\Debug\net46\win7-x64\publish or copy project.json .\bin\Release\net46\win7-x64\publish

I bundle up a few more things into publish.... migrations, and app_offline.htm, and push it to an octopus server for deployment.

[MichaelGiger]

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

[ChristianSacramento]

@MichaelGiger

https://github.com/aspnet/Tooling/issues/813#issuecomment-257739697

[robrich502]

I was having the issue above (couldn't restore referenced libraries in a csproj), building in TFS 2015.

I was able to successfully restore the packages after using the newer version of Nuget.exe (v3.5.0).

[MichaelGiger]

@robrich22 I tried it also with the version 3.5.0 (RC2), but it did not work. I suspect that it has to do with the dependency (AspNetCoreNetFrameworkDemo -> CL1)

@ChristianSacramento That's exaclty the way I did it. I hope that this will be fixed in future...

[milla]

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.

[jsgoupil]

This is working fine on my computer but I can't deploy on Azure... 👎
Unable to resolve 'Project.Common' for '.NETFramework,Version=v4.6'.

[kubarom]

@milla: worked for me as well

[MarkPerryBV]

I have had to commit project.fragment.json to my Git repo in order for the solution to build on TeamCity. I have a asp.net core project which references several .net 4.6.2 class libraries. Took a long time to figure out that the build sever could NOT generate that project.fragment.lock using either MSBuild or VSBuild tasks in TeamCity.

[cScarlson]

I was trying to install EntityFramework in my project.json dependencies (because of NuGet GUI install), which looked like this:

"EntityFramework": "6.0.1"

But when I looked into project.json, I noticed an error. What I needed was,

"Microsoft.EntityFrameworkCore": "1.0.1"

Be sure you're not falling into that trap like me :-P

[TheRealPiotrP]

Thanks @cScarlson

In general, this is a project.json issue and has been overridden by the preview3+ tooling and csproj. I'm going to close this one, but please open a new one if you see similar problems in csproj.