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: 1e9d529

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.

[SuperJMN]

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

[TheRealPiotrP]

@rpokrovskij you can get latest command-line tools and VS tools in the Visual Studio 2017 RC. If you want to try just the command-line tools, you can get the absolute latest from the root of this repo. You can also get the version that shipped in the latest Visual Studio 2017 RC from the links in dotnet/cli#4938. If not installing Visual Studio I'd recommend grabbing the latest build as we're getting a lot of feedback via issues here and are rapidly fixing and pushing out new builds.

[rpokrovskij]

@piotrpMSFT I am tired to struggle with "release" VS version (core / xproj) and the idea to move to VS RC scare me a lot. Surprise.

The alternative way: VS 2015 + "latest command-line tools" seems more attractive for me. It would be nice if there would be a one page documentation how to deploy "latest root of this repo" and how to use them (wiht xproj? with csproj?) ...

[TheRealPiotrP]

fair enough @rpokrovskij :)

@blackdwarf likely has the doc you're looking for. In general, though:

• The VS 2015 preview tools for .NET Core work with dotnet CLI preview2 and earlier. The project.json + xproj project system is supported with these components. The team is making minimal changes to this version of the tools and has no plan to move them past the preview stage.
• VS 2017 RC+ works with .NET CLI preview3+. Starting with preview3 the CLI removed support for project.json + xproj and adopted msbuild + csproj. This release also introduced a dotnet migrate gesture to help folks move their projects forward to csproj.

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

[rpokrovskij]

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.

[timotyweis]

I've spent again a few hours on this. My current setup is the following:

• 74 projects (33 test projects)
  • 73 projects targeting .NET Framework 4.5.2
  • 1 ASP.NET Core Web Application targeting .NET Framework 4.5.2
• Development machine
  • Windows 10
  • VS2015 Update 3
  • .NET Core 1.0.3 (1.0.0-preview2-003156)
• Build Server
  • Windows Server 2012 R2 Datacenter (on Azure)
  • TeamCity Professional 10.0.2
  • Nuget 3.5.0
  • .NET Core 1.0.3 (1.0.0-preview2-003156)

Everything builds and runs properly on my machine using VS.

In order to keep the CI going, I've currently setup a second solution file with only the .NET projects that I build normally in TC. I've also stripped everything out of the ASP.NET Core project (I've only the Program.cs and project.json, everything else is in a .NET 4.5.2 class library that can be build in TC).

I've configured another TC configuration using all the latest tools suggested. I managed to restore the packages with Nuget (but I noticed that the default dependencies like Microsoft.Extensions.Logging.Console in the project.json were missing in the packages folder). However, the dotnet build src/**/project.json --configuration Release command still fails (with the same message as @SuperJMN ):

[13:08:35]Step 4/6: Build (.NET Core (dotnet)) (1m:38s)
[13:08:35][Step 4/6] Starting: "C:\Program Files\dotnet\dotnet.exe" build src/**/project.json --configuration Release
[13:08:35][Step 4/6] in directory: C:\TeamCity\BuildAgent2\work\cefc4b729ebeac0a
[13:08:36][Step 4/6] 
[13:08:36][Step 4/6] Welcome to .NET Core!
[13:08:36][Step 4/6] ---------------------
[13:08:36][Step 4/6] 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.
[13:08:36][Step 4/6] Telemetry
[13:08:36][Step 4/6] --------------
[13:08:36][Step 4/6] 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.
[13:08:36][Step 4/6] You can opt out of telemetry by setting a DOTNET_CLI_TELEMETRY_OPTOUT environment variable to 1 using your favorite shell.
[13:08:36][Step 4/6] You can read more about .NET Core tools telemetry @ https://aka.ms/dotnet-cli-telemetry.
[13:08:36][Step 4/6] Configuring...
[13:08:36][Step 4/6] -------------------
[13:08:36][Step 4/6] 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.
[13:08:47][Step 4/6] Decompressing 0%                Decompressing 1%                Decompressing 2%                Decompressing 3%                Decompressing 4%                Decompressing 5%                Decompressing 6%                Decompressing 7%                Decompressing 8%                Decompressing 9%                Decompressing 10%                 Decompressing 11%                 Decompressing 12%                 Decompressing 13%                 Decompressing 14%                 Decompressing 15%                 Decompressing 16%                 Decompressing 17%                 Decompressing 18%                 Decompressing 19%                 Decompressing 20%                 Decompressing 21%                 Decompressing 22%                 Decompressing 23%                 Decompressing 24%                 Decompressing 25%                 Decompressing 26%                 Decompressing 27%                 Decompressing 28%                 Decompressing 29%                 Decompressing 30%                 Decompressing 31%                 Decompressing 32%                 Decompressing 33%                 Decompressing 34%                 Decompressing 35%                 Decompressing 36%                 Decompressing 37%                 Decompressing 38%                 Decompressing 39%                 Decompressing 40%                 Decompressing 41%                 Decompressing 42%                 Decompressing 43%                 Decompressing 44%                 Decompressing 45%                 Decompressing 46%                 Decompressing 47%                 Decompressing 48%                 Decompressing 49%                 Decompressing 50%                 Decompressing 51%                 Decompressing 52%                 Decompressing 53%                 Decompressing 54%                 Decompressing 55%                 Decompressing 56%                 Decompressing 57%                 Decompressing 58%                 Decompressing 59%                 Decompressing 60%                 Decompressing 61%                 Decompressing 62%                 Decompressing 63%                 Decompressing 64%                 Decompressing 65%                 Decompressing 66%                 Decompressing 67%                 Decompressing 68%                 Decompressing 69%                 Decompressing 70%                 Decompressing 71%                 Decompressing 72%                 Decompressing 73%                 Decompressing 74%                 Decompressing 75%                 Decompressing 76%                 Decompressing 77%                 Decompressing 78%                 Decompressing 79%                 Decompressing 80%                 Decompressing 81%                 Decompressing 82%                 Decompressing 83%                 Decompressing 84%                 Decompressing 85%                 Decompressing 86%                 Decompressing 87%                 Decompressing 88%                 Decompressing 89%                 Decompressing 90%                 Decompressing 91%                 Decompressing 92%                 Decompressing 93%                 Decompressing 94%                 Decompressing 95%                 Decompressing 96%                 Decompressing 97%                 Decompressing 98%                 Decompressing 99%                 Decompressing 100% 10723 ms
[13:09:31][Step 4/6] Expanding 0%            Expanding 1%            Expanding 2%            Expanding 3%            Expanding 4%            Expanding 5%            Expanding 6%            Expanding 7%            Expanding 8%            Expanding 9%            Expanding 10%             Expanding 11%             Expanding 12%             Expanding 13%             Expanding 14%             Expanding 15%             Expanding 16%             Expanding 17%             Expanding 18%             Expanding 19%             Expanding 20%             Expanding 21%             Expanding 22%             Expanding 23%             Expanding 24%             Expanding 25%             Expanding 26%             Expanding 27%             Expanding 28%             Expanding 29%             Expanding 30%             Expanding 31%             Expanding 32%             Expanding 33%             Expanding 34%             Expanding 35%             Expanding 36%             Expanding 37%             Expanding 38%             Expanding 39%             Expanding 40%             Expanding 41%             Expanding 42%             Expanding 43%             Expanding 44%             Expanding 45%             Expanding 46%             Expanding 47%             Expanding 48%             Expanding 49%             Expanding 50%             Expanding 51%             Expanding 52%             Expanding 53%             Expanding 54%             Expanding 55%             Expanding 56%             Expanding 57%             Expanding 58%             Expanding 59%             Expanding 60%             Expanding 61%             Expanding 62%             Expanding 63%             Expanding 64%             Expanding 65%             Expanding 66%             Expanding 67%             Expanding 68%             Expanding 69%             Expanding 70%             Expanding 71%             Expanding 72%             Expanding 73%             Expanding 74%             Expanding 75%             Expanding 76%             Expanding 77%             Expanding 78%             Expanding 79%             Expanding 80%             Expanding 81%             Expanding 82%             Expanding 83%             Expanding 84%             Expanding 85%             Expanding 86%             Expanding 87%             Expanding 88%             Expanding 89%             Expanding 90%             Expanding 91%             Expanding 92%             Expanding 93%             Expanding 94%             Expanding 95%             Expanding 96%             Expanding 97%             Expanding 98%             Expanding 99%             Expanding 100% 44507 ms
[13:10:13][Step 4/6] Lock file Microsoft.DotNet.ProjectModel.Graph.LockFile contains msbuild projects but there is no export file
[13:10:14][Step 4/6] Process exited with code 1
[13:10:14][Step 4/6] Step Build (.NET Core (dotnet)) failed

Kind of frustrating. I'll keep going with my second "standard .NET only" solution and using the ASP.NET core project as a mere entry point for the application. However, this will have impacts over the deployment for which I've no workaround right now.

[cdwaddell]

What is in your global.json? It looks like your CL1 project is outside of your src folder.

[RichDef77]

@piotrpMSFT How can we deploy to Azure? I'm having the same problem @jsgoupil is having. I don't think this problem should be closed as there is no clear cut solution specified.

[squid16]

Hi everyone,
By making changes to project.json (below), I was be able to add a reference to my classic non-core class library from .NET Core Web Application. I did see the added library listed under ".NET Framework 4.6.1" in the References section in my Web Application. However, as I compiled the project, I got the below error,
Severity Code Description Project File Line Suppression State
Error CS0246 The type or namespace name 'XXX' could not be found (are you missing a using directive or an assembly reference?) WebApplication1..NETCoreApp,Version=v1.0 C:\qs\proj\test\VS2015\WebApplication1\src\WebApplication1\Program.cs 6 Active
where XXX is the name of my ASP.NET library.
Also, as I hover my mouse over "Using XXX" in my class, I got a warning saying
WebApplication1..NET Framework 4.6.1 - Available
WebApplication1..NETCoreApp,Version=v1.0-Not Available
I'm using Visual Studio 15 on Windows 10.
It looks like I successfully added the reference to the non-core XXX library from my core Web Application, but when building the core Web Application, the added XXX library cannot be seen.
Please help me out!
Thanks for your time!

Below is my project.json:
{
"dependencies": {
"Microsoft.ApplicationInsights.AspNetCore": "1.0.0",
"Microsoft.AspNetCore.Diagnostics": "1.0.0",
"Microsoft.AspNetCore.Mvc": "1.0.1",
"Microsoft.AspNetCore.Razor.Tools": {
"version": "1.0.0-preview2-final",
"type": "build"
},
"Microsoft.AspNetCore.Routing": "1.0.1",
"Microsoft.AspNetCore.Server.IISIntegration": "1.0.0",
"Microsoft.AspNetCore.Server.Kestrel": "1.0.1",
"Microsoft.AspNetCore.StaticFiles": "1.0.0",
"Microsoft.Extensions.Configuration.EnvironmentVariables": "1.0.0",
"Microsoft.Extensions.Configuration.Json": "1.0.0",
"Microsoft.Extensions.Logging": "1.0.0",
"Microsoft.Extensions.Logging.Console": "1.0.0",
"Microsoft.Extensions.Logging.Debug": "1.0.0",
"Microsoft.Extensions.Options.ConfigurationExtensions": "1.0.0",
"Microsoft.VisualStudio.Web.BrowserLink.Loader": "14.0.0"
},

"tools": {
"BundlerMinifier.Core": "2.0.238",
"Microsoft.AspNetCore.Razor.Tools": "1.0.0-preview2-final",
"Microsoft.AspNetCore.Server.IISIntegration.Tools": "1.0.0-preview2-final"
},

"frameworks": {
"netcoreapp1.0": {
"imports": [
"dotnet5.6",
"dnxcore50",
"portable-net45+win8"
],
"dependencies": {
"Microsoft.NETCore.App": {
"version": "1.0.0",
"type": "platform"
}
}
},
"net461": {
"dependencies": {
"TCShipping": "1.0.0"
}
}
},

"buildOptions": {
"emitEntryPoint": true,
"preserveCompilationContext": true
},

"runtimeOptions": {
"configProperties": {
"System.GC.Server": true
}
},

"publishOptions": {
"include": [
"wwwroot",
"**/*.cshtml",
"appsettings.json",
"web.config"
]
},

"scripts": {
"prepublish": [ "bower install", "dotnet bundle" ],
"postpublish": [ "dotnet publish-iis --publish-folder %publish:OutputPath% --framework %publish:FullTargetFramework%" ]
}
}

[RichDef77]

Hi There @squid16,

I think you need to remove the .Net Core entry from your frameworks section. Try removing this part:

netcoreapp1.0": {
"imports": [
"dotnet5.6",
"dnxcore50",
"portable-net45+win8"
],
"dependencies": {
"Microsoft.NETCore.App": {
"version": "1.0.0",
"type": "platform"
}
}
Hope that helps!

[squid16]

Hello @RichDef77 ,
Thanks so much for your advice and your time! That did it. I'm now able to build and run my project!
I would like to ask you another question, please.
When i clicked on the References section in Visual Studio now, only the ".NET Framework 4.6.1" is listed. The ".NETCoreApp,Version=1.0" was removed. Both of them were there earlier.
Can you please let me know if removing .Net Core entry from the frameworks section means that my project is no longer a .NET core Web Application project but instead is just a .NET Web Application project?
Thanks again!!

[RichDef77]

Hi @squid16,

I'm pretty sure your app is still a .Net Core app - however its now running on top of the full .Net Framework 4.6.1 rather than the pared down cross-platform .Net Core 1.0 Framework. This means that you can reference and leverage full .Net Framework class libraries and projects - but it also means that you sacrifice the cross-platform capabilities.

Scott Hanselman has a great blog post on this: http://www.hanselman.com/blog/HowToReferenceAnExistingNETFrameworkProjectInAnASPNETCore10WebApp.aspx

That diagram at the top of the post illustrates this well.

I hope that helps!

[squid16]

@RichDef77 ,
Thanks so much for your explanation and the link! It's all making senses now :)

[wburgers]

This finally makes some sense to me, though I still think it is broken.
First let me sketch the situation:
I want to publish a dotnet core app that references some class libraries and thus builds on the full net452 framework.

If I try to use dotnet restore on the full solution, the tooling is unable to resolve the references to multiple class libraries.
Unable to resolve 'ClassLibrary1' for '.NETFramework,Version=v4.5.2'.

Nuget 3.5 can actually resolve those dependencies and brings me one step further.
If I try to publish the dotnet core app with dotnet publish, I get the error some others above also mentioned.
Lock file Microsoft.DotNet.ProjectModel.Graph.LockFile contains msbuild projects but there is no export file
This error makes no sense at all, but means that the project.fragment.lock.json file is missing from the project folder.
The weird thing is that dotnet restore does actually create a project.fragment.lock.json file, but it contains the same errors as the project.lock.json files, so publishing won't work, because it is still unable to resolve some dependencies.

I set out to check when Visual Studio creates the project.fragment.lock.json file, because I noticed that it is not created on loading the project, but it exists when I try to run the project.
Visual Studio just builds the project using dotnet build with a --no-dependencies flag.
This step creates the needed project.fragment.lock.json file!

So what I did on our jenkins build is the following:
Use nuget 3.5 to restore the packages (for the entire solution).
run msbuild on the entire solution (this generates the project.fragment.lock.json for all dotnet core projects in the solution.)
and finally publish the dotnet core app(s) with dotnet publish.

Now I seem to have a working build, although we also have another build slave that does not work due to some unknown problem, but that looks unrelated.
I hope this helps some people solving the Lock file Microsoft.DotNet.ProjectModel.Graph.LockFile contains msbuild projects but there is no export file error

[tmarinov]

Ok, after spending 2 days in trying to investigate this problem I managed to fix it (not in a best way, but..).
here is my scenario:

VS 2015, dotnet version: 1.0.0-preview2-003156
Solution_1 with a number classic libraries projects, migrated to reference framework 4.6.1.
Solution_2 - .NetCore webapi with a number of .netcore libraries using full framework 4.6.1.
.net core libraries reference (as projects) classic libraries from solution_1:

Solution_1 Folder
|
Classic library0 / folder
|
Classic library1 / folder
|
Classic library_n-1 / folder
|
Solution_2 SubFolder
|
Core library0 / folder
|
Core library1 / folder
|
Core library_n-1 / folder

As I said, there are a number of project references from core libraries to classic libraries.

Problem

First problem appeared on our CI TFS build at the very first task - Nuget restore (nugget ver. 3.5).
We got a number of messages "Unable to resolve 'Classic_Library_Name_Here'" for '.Net Framework 4.6.1'.
If I restore packages from VS - it works.
If I restore packages from command line by using dotnet restore <.sln file> - doesn't work
If I restore packages from command line by using nuget restore <.sln file> - doesn't work
Same result with .xproj files.

Solution:

Step 1: Created a new build task that builds my Solution1 (containing classic libraries). I needed this build task in order to get the classic dll binaries at very first place. This was the first reason why it couldn't resolve the binaries. Put this task to be executed first.

Step 2: Modified all the project.fragment.lock.json files that have references to the classic libraries - they must use

the correct relative paths. The paths, added by VS were wrong since the projects are in upper folders than the webapi

solution and how they were written initially was like they are subfolders of Solution_2.
This was the second reason why it couldn't resolve the binaries.
Important: After you change these files you must check them in t o source control before any Build of the solution on your machine, since they will be overwritten with the default values.

project.fragment.lock.json snippet example before:
"Classic_Library_Name_Here/1.0.0": { "type": "project", "framework": ".NETFramework,Version=v4.6.1", "compile": { "bin/debug/Classic_Library_Name_Here.dll": {} }, "runtime": { "bin/Debug/Classic_Library_Name_Here.dll": {} }, "contentFiles": { "/bin/Debug/Classic_Library_Name_Here.pdb": { "buildAction": "None", "codeLanguage": "any", "copyToOutput": true }}},

project.fragment.lock.json snippet example after:
"Classic_Library_Name_Here/1.0.0": { "type": "project", "framework": ".NETFramework,Version=v4.6.1", "compile": { "../../../bin/debug/Classic_Library_Name_Here.dll": {} }, "runtime": { "../../../bin/Debug/Classic_Library_Name_Here.dll": {} }, "contentFiles": { "../../../bin/Debug/Classic_Library_Name_Here.pdb": { "buildAction": "None", "codeLanguage": "any", "copyToOutput": true }}},

Step 3: Create a NuGet restore task and place it on second place - right after the task that builds Solution_1.

This way, the first task will build the classic libraries solution and we will get the binaries (expected "packages" by nuget) and they will be available for .net core projects through the correct modified project.fragment.lock.json files

Of course, now with every new reference to a classic project I need to change the project.fragment.lock.json file, but until there a solution provided by Microsoft, this is the workaround worked for us.

[hvetter-de]

problem still exists for me with latest VS2017(RTW)

Restoring NuGet packages... Unable to resolve 'C:\git\daenet.vs\xxxServices\xxService\xxx.IotHubNet45\xxx.IotHubNet45.csproj' for '.NETFramework,Version=v4.6.1'. Unable to resolve 'C:\git\daenet.vs\xxxServices\xxService\xxx.IotHubNet45\xxx.IotHubNet45.csproj' for '.NETFramework,Version=v4.6.1 (win7-x64)'. NuGet package restore failed.

Build is fully working and the application works, but those errors are confusing.

UPDATE: Sorry if this wasn't related to this issue.
FYI: Fixed this issue by looking at how the VS2017 RTW creates new projects and change proj files regarding to this. Seems like it was a VS2017 RC xproj->csproj migration problem.

[fubar-coder]

@Niyo The error you get (.NET Tooling 1.0 RTM) seems to be different from the error discussed here (.NET Tooling 1.0-preview2-1). Maybe you should open a new ticket?

[RichDef77]

Hi @squid16 sorry for the delay in my response ... your app is still a .Net Core app but its now running on top of the full .Net 4.6.1 framework. So you get the best of both worlds - the benefits of .Net Core (new routing, DI, all that good stuff) as well as the full .Net Framework APIs. The only thing to remember is that you lose the cross platform capabilities of .Net Core as the full .Net Framework only runs on Windows.

[colltoaction]

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.

[StenPetrov]

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?

[stonstad]

Ugh, this is still happening with VS 2017 Update 1. It can be easily reproduced by creating a new .NET Core Web project (using .NET Framework) and then add a reference to an existing .NET library class (csproj).

Update: the behavior I am experiencing was caused by a space in the file path, i.e. "Visual Studio 2017\projects". Nuget package restore fails for me when .NET Framework projects are added (as project references) and the associated file path contains a space. Moving my top level folder to "C:\a" allows me to work past this issue.

[chrisrharris]

Lightweight solution loading seemed to be the culprit for me in VS 2017 15.1. I noticed when the projects weren't fully loaded, my nuget restore was failing.

[winfredchen]

I I have the same problem for framework 4.5.2, it works in VS2017.

it resolved by install the framework 4.5.2 developer pack: http://getdotnet.azurewebsites.net/target-dotnet-platforms.html

[robcube]

I solved this by moving my project from the default c:...\Visual Studio 2017\Projects\ to, say, c:\git. Moving your solution to a folder with no spaces in them might do the trick; what @stonstad suggested.

[alexoragz]

Not sure if this helps anyone but I had success by deleting the project.json, project.lock.json, and all the contents of my packages folder.

I then reopened the solution in VS and did a right click -> restore nuget packages which was successful as well as subsequent builds.

[mvximvs]

After removing the "-" of the solution name and references and rebuild the namespaces has worked for me :-).

[Inrego]

I can also confirm issues with spaces in path to project reference, as @stonstad pointed out.

[sudogooglex]

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

[socertis]

as a workaround, i have used one of those Nuget files, available here https://www.nuget.org/downloads and paste it in the /.nuget folder. and it worked.