search

dotnet / sdk

Core functionality needed to create .NET Core projects, that is shared between Visual Studio and CLI
https://dot.net/core
MIT License
2.67k stars 1.06k forks source link

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

Closed timotyweis closed 4 years ago

timotyweis commented 8 years ago

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
rpokrovskij commented 7 years ago

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

rpokrovskij commented 7 years ago

@milla it is easy to trick VS to do not show "referencing" errors by manipulating them. But e.g. core web app will still not work if you launch it (or will stop working when you will remove cache). dotnet restore --no-cache should work - only that can guarantee that solution will work on other developer's PC.

SuperJMN commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

fair enough @rpokrovskij :)

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

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

rpokrovskij commented 7 years ago

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 commented 7 years ago

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

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 commented 7 years ago

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

RichDef77 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

wburgers commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

Inrego commented 7 years ago

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

sudogooglex commented 6 years ago

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

socertis commented 6 years ago

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.