-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dotnet restore unable to resolve .NET Framework libraries (4.5.2, 4.6.2) #6224
Comments
I have the same problem for net451: it works in VS, but does not work with dotnet restore. |
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'."
|
@timotyweis Your "Actual behaviour" error message refers to '.NETFramework,Version=v4.5.2'. - shouldn't it be '.NETFramework,Version=v4.6.2'.? |
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. |
@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) |
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 |
Mine is csproj based, yes. |
Still no workaround? This is a blocker for me that prevents to upgrade on RC2. |
@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. |
Closed due to duplication |
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. |
@barynov If you prefer I may reopen the Issue and we'll wait for more detail. |
@timotyweis Please re-open the issue and I will provide a sample to reproduce it. |
@barynov Here you go |
The Nuget issue to follow: NuGet/Home#2865 |
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. 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 The contents of restore.dg are
That however only generates a project.lock.json, and if we try to 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.
In your build server just execute 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. |
PLEASE FIX IT ASAP! I cannot integrate any code in my ASP.Net Core (.Net Framework) application. All work is stopped! |
Workaround: Use a 3.5 (Beta) version of Nuget.exe and run "nuget restore" instead of "dotnet restore". Credit to @emgarten for suggesting this. |
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 upgraded to the RTM version, but still have to use restore.dg workaround for TFS builds, because |
@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
so I would think that means the RTM Running either still results in |
Following up on my previous post, I found another workaround: If you have a single .csproj project referenced in a project.json web app, |
This workaround seems to work for me:
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:
Is there still no other workaround less complicated than the ones in this issue? |
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 |
@KonbOgonb solution worked for me too. Use NuGet.exe restore aPathToYour.sln (nuget 3.5 at least) |
The 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]. |
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.
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. |
I'm getting this:
When running dotnet build. This is my version: Microsoft .NET Core Shared Framework Host Version : 1.1.0 |
@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. |
@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?) ... |
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. |
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'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
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. |
What is in your global.json? It looks like your CL1 project is outside of your src folder. |
@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. |
Hi everyone, Below is my project.json: "tools": { "frameworks": { "buildOptions": { "runtimeOptions": { "publishOptions": { "scripts": { |
Hi There @squid16, I think you need to remove the .Net Core entry from your frameworks section. Try removing this part: netcoreapp1.0": { |
Hello @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! |
@RichDef77 , |
This finally makes some sense to me, though I still think it is broken. If I try to use dotnet restore on the full solution, the tooling is unable to resolve the references to multiple class libraries. Nuget 3.5 can actually resolve those dependencies and brings me one step further. 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. So what I did on our jenkins build is the following: 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. |
Ok, after spending 2 days in trying to investigate this problem I managed to fix it (not in a best way, but..). VS 2015, dotnet version: 1.0.0-preview2-003156 Solution_1 Folder As I said, there are a number of project references from core libraries to classic libraries. ProblemFirst problem appeared on our CI TFS build at the very first task - Nuget restore (nugget ver. 3.5). 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. project.fragment.lock.json snippet example before: project.fragment.lock.json snippet example after: 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. |
problem still exists for me with latest VS2017(RTW)
Build is fully working and the application works, but those errors are confusing. UPDATE: Sorry if this wasn't related to this issue. |
@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? |
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. |
Just to clarify: those are features of the new ASP.NET Core framework, which happens to work in both .NET Framework and .NET Core. |
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? |
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. |
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. |
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 |
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. |
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. |
After removing the "-" of the solution name and references and rebuild the namespaces has worked for me :-). |
I can also confirm issues with spaces in path to project reference, as @stonstad pointed out. |
I just had to do a |
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. |
Steps to reproduce
In Visual Studio 2015
dotnet restore
from the command lineExpected behavior
dotnet restore
completes without errors.Actual behavior
The command terminates with the following error message:
In Visual Studio I can restore the packages and compile the application without any problem.
Environment data
dotnet --info
output:The text was updated successfully, but these errors were encountered: