Unable to find nuget local source error occurred while restoring nuget packages the local source doesn't exist - visual-studio-2017

I've been given a visual studio 2017 solution. When I open it fails as with the error:
Error occurred while restoring NuGet packages: The local source '\\network-location\' doesn't exist.
I can manually acquire a copy of these packages but I don’t know where this original path is configured and how I would go about changing it to the new location.
Any suggestions as to where I should look please?

The package sources can be found in the Visual Studio options (Tools -> Options) under NuGet Package Manager -> Package Sources or directly by clicking on the according icon in the NuGet dialog (context menu of a solution/project -> Manage NuGet Packages...):
Your local package source should then be listed in the following dialog:
The package source may, however, be solution or project specific and may therefore be specified in a NuGet.config file in the solution directory. Beginning with NuGet 3.4, Visual Studio looks in the project's directory or "or any folder up to the drive root", according to the NuGet.config reference. Up to NuGet 3.3, also subdirectories with the name .nuget where searched for NuGet.config files.
The file containing your local package source must be changed in order to restore the correct packages.

Nothing of the proposed solutions above did it for me. And, honestly, I really don't like, what Microsoft is doing for some time now: each time there's another surprise when installing an update. :-(
Analysis:
Error occurred while restoring NuGet packages: The local source 'C:\Microsoft\Xamarin\NuGet' doesn't exist.
Obviously NuGet is trying to restore from C:\\Microsoft\\Xamarin\\NuGet for s solution that has nothing to do with Xamarin. The solution compiled many times before and even getting it back from GIT did not change anything. So, the problem is not my solution. It is something more global.
By the way: I DONT WANT TO USE THIS FOLDER, cause I don't use Xamarin!
I found the following reference in the *.csproj.nuget.dgspec.json files in any obj folder of my solution. All these json files pointed to this Xamarin folder:
"fallbackFolders": {
"C:\\Microsoft\\Xamarin\\NuGet": {},
"C:\\Program Files (x86)\\Microsoft SDKs\\NuGetPackages\\": {},
"https://api.nuget.org/v3/index.json": {}
},
Question: How does VS know about the fallbackFolders?
I did not find any hint in any of my Visual Studio / NuGet configuration settings, as proposed above. I deleted all objfolder but each time when trying to compile or restore my packages, the reference came back.
The SOLUTION for me was :
delete all objfolders in your solution (as mentioned above)
delete c:\Program Files (x86)\NuGet\Config\Xamarin.Offline.config
There you will find the following:
<fallbackPackageFolders>
<add key="Xamarin Offline Packages" value="C:\Microsoft\Xamarin\NuGet\"/>
</fallbackPackageFolders>
This file was introduced on my machine one week ago, and I think it came with the latest VS update (16.2). I did not go away with the latest update (16.2.1) from today.

You will encounter the same issue in Visual Studio 2019. I have the same issue, I thought it was a conflict on Visual Studio 2017 but it wasn't.
The fix is you have to remove the source that is causing the issue.
You can remove it via Tools -> NuGet Package Manager -> Package Manager Settings

In my case i have getting this error:
Error occurred while restoring NuGet packages: The local source 'C:\Microsoft\Xamarin\NuGet' doesn't exist.
I have accidentally deleted 'C:\Microsoft\Xamarin\' folder.
After this VS2019 was not able to restore packages.
I just manually created 'C:\Microsoft\Xamarin\NuGet' folder.
Restarted VS, cleaned solution and everything goes well after this.

All answers are relevant however they are not complete, wasted 30 mins on this.
Below worked fine:
1 . Clear cache & remove issue folders:
Tools > NuGet Package Manager > Package Manager Settings
> NuGet Package Manager > General > Clear All NuGet Cache(s)
Tools > NuGet Package Manager > Package Manager Settings
> NuGet Package Manager > Package Sources
> Available package sources
> {uncheck the folder that is giving error}
> OK
2 . Restore NuGet Packages on VS Solution
Right-click on Visual studio solution (not project)
> Restore NuGet Packages
3 . Build & run project
Hope that helps.

I had this error in different situation. I checked contents of Nuget.config in my solution folder and under <packageSources> node it had an entry pointing to ./nuget. This folder didn't exist in the solution directory, so I just created an empty folder with this name and the solution compiled without any problems.

In My case the only way to solve it was to clean up all the NuGet cache(s).
You can find it at Tools -> NuGet Package Manager -> General
Clear All NuGet Cache(s) print

but I don’t know where this original path is configured and how I would go about changing it to the new location.
To resolve this error, please search the file NuGet.config in the given solution, then edit it with notepad, you will find following setting in that file:
<packageSources>
<add key="LocalServerName" value="\\network-location\" />
</packageSources>
You could change the value to the new location.

Same situation:
Error occurred while restoring NuGet packages: The local source 'C:\Program Files (x86)\Microsoft Visual Studio\Shared\NuGetPackages' doesn't exist.
My solution is re-creating the folder.

Related

VS 15.8.2 broke build tools - missing RuntimeIdentifier

The last windows update has broken our whole build chain and I am a little at a loss at what causes it.
I have a legacy project that is a VS 2017 solution with a significant number of projects (winform, couple web based, some Webapi only).
Locally things work perfectly. I can just build them.
On the server, the proejct has started to fail, and the error is:
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\NuGet\15.0\Microsoft.NuGet.targets(186,5): Error : Your project file doesn't list 'win' as a "RuntimeIdentifier". You should add 'win' to the "RuntimeIdentifiers" property in your project file and then re-run NuGet restore.
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\NuGet\15.0\Microsoft.NuGet.targets(186,5): Error : Your project file doesn't list 'win' as a "RuntimeIdentifier". You should add 'win' to the "RuntimeIdentifiers" property in your project file and then re-run NuGet restore.
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\NuGet\15.0\Microsoft.NuGet.targets(186,5): Error : Your project file doesn't list 'win' as a "RuntimeIdentifier". You should add 'win' to the "RuntimeIdentifiers" property in your project file and then re-run NuGet restore.
Process 'msbuild.exe' exited with code '1'.
I have added
<RuntimeIdentifiers>win</RuntimeIdentifiers>
To a number of projects. No change. I am at a loss, because the error message does not even tell me which project.
At some point before attempting to build, you need to delete the obj folder.
More than one person showed this to solve the problem.
https://developercommunity.visualstudio.com/content/problem/312180/projects-fail-to-build-in-1580-due-to-errors-from.html
Although #Señor CMasMas's answer has helped me in the past, I'm now finding (since installing the .NET Core SDK v2.2 - I don't know if that's related though) that I also need to close and reopen Visual Studio. So for me the recipe is:
Clean solution
Delete obj folders
Delete the .vs folder (optional, if you get red lines but it builds OK)
Close and reopen Visual Studio
Then build
Add this: <RuntimeIdentifier>win</RuntimeIdentifier>
to your project file, for example after element TargetFrameworkVersion. Make sure the element name is singular. RuntimeIdentifiers on the other hand is used in the new csproj format
Or you just can run in the root directory of your project the script in PowerShell that you should run as administrator.
Get-ChildItem .\ -include bin,obj -Recurse | foreach { remove-item $_.fullname -Force -Recurse }
this script will delete all obj and bin folders
I have come across same error in Vs 2019 (16.8.6), following steps resolved my problem.
Close visual studio (other visual studio instances may remain)
Delete all bin and obj folders in all projects in the solution
Reopen solution and Build
Note that if bin folders exist, deleting only obj folders doesn't work, you need to delete bin folders too.
Had this problem in projects using packageReference when manually restoring packages by running
NuGet.exe restore my.sln
as part of a TeamCity build (so might be related nf313743's answer https://stackoverflow.com/a/60951212/128384) and then building projects using msbuild.
This would result in the following error when msbuild begins dealing with the PackageReference:
[ResolveNuGetPackageAssets] C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\NuGet\15.0\Microsoft.NuGet.targets(186, 5):
Your project file doesn't list 'win-x86' as a "RuntimeIdentifier". You should add 'win-x86' to the "RuntimeIdentifiers" property in your project file and then re-run NuGet restore.
Deleting obj directories etc doesn't work here because they get added by the restore step; adding a RuntimeIdentifier might, but building the exact same on a VS2017 commandline works fine so clearly the difference is in how TeamCity sets up the environment.
The culprit could be found in the output of the first call:
NuGet.exe restore my.sln -NonInteractive
MSBuild auto-detection: using msbuild version '16.10.2.30804'
from 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\bin'.
it uses msbuild from the VS2019 installation whereas the project is being built by VS2017, so somewhere in mixing those there is an incompatibility which is not unexpected. Anyway, the key is likely that TeamCity doesn't setup a complete environment like the VS2017 commandline does and the NuGet documentation says
By default the MSBuild in your path is picked,
otherwise it defaults to the highest installed version of MSBuild.
so that's why it uses the VS2019 one. Solution is to manually pass -MsBuildPath to NuGet and set it to what corresponds to the selected buildtools in teamCity, in this case:
NuGet.exe -msBuildPath "%MSBuildTools15.0_x86_Path%" restore my.sln
(and it turns out teamCity itself is also plagued by this in its own NuGet step: How to set the MSBuild verision for TeamCity NuGet Installer?)
I have a similar case. I try to build a solution via msbuild without installing Visual Studio 2017, just install the latest version of vs 2017 build tools. Here are my steps:
dotnet restore a.sln
(There are some .Net Standard Library project in this solution, the others are .NET 4.7.2 projects).
call msbuild.exe to build this solution.
I got the error of "missing RuntimeIdentifier".
Your project file doesn't list 'win' as a "RuntimeIdentifier". You should add 'win' to the "RuntimeIdentifiers" property in your project file and then re-run NuGet restore.
It seems an issue in the old version of Nuget. Please refer here. Finally, I resolved it via restore packages with the latest Nuget (v5.0.2).
the steps:
Delete obj and bin folders
nuget.exe restore a.sln
call msbuild.exe
I had a similar problem. My error was
error : Your project file doesn't list 'win10' as a
"RuntimeIdentifier". You should add 'win10' to the
"RuntimeIdentifiers" property in your project file and then re-run
NuGet restore.
Well, it turned out I just had to change by build target from "Any CPU" to something else (x64 for example)...
you got to figure out which projects in your solution trigger this error. you can find this if you look at the error panel.
go to that projects locations and delete both the bin and the obj folders.
then rebuild.
should be alright
I had this same issue toggling across vstools build chains (VS2017/VS2019) - here is what fixed it for me - brute force clean via rimraf
Your project file doesn't list 'win' as a "RuntimeIdentifier". You should add 'win' to the "RuntimeIdentifiers" proper ty in your project file and then re-run NuGet restore
Remove Intermediary Build Output Artifacts
rimraf *\obj\**
The RuntimeIdentifier should look something more like what's described here: https://learn.microsoft.com/en-us/dotnet/core/rid-catalog.
Given this appears to build just find locally, I'd diff the .csproj on your local machine against the one on your build server. Something tells me, they are not identical.
FWIW, Line 186 in the noted Microsoft.NuGet.targets file, is running the ResolveNuGetPackageAssets task, and you can see the RuntimeIdentifier argument being passed as the NuGetRuntimeIdentifier property. You could probably backtrace that in your working build's diagnostic log to see how it's being assigned.
But given this works on one box, and not on another, I'd just dbl check your project files and verify that the RuntimeIdentifier tag identical on both systems.
Sincerely,
So I was seeing the same error message as this on our on premises DevOps build server, but it built fine locally in Visual Studio as well as via the msbuild on the command line.
I checked and I DID have the <RuntimeIdentifiers> defined in my project file and clearing out the obj and bin folders on the server did NOT fix it for me.
Our issue was we had the < RunTimeIdentifiers> tag showing up MULTIPLE times in the build section,(probably from a bad merge at some point in the past). After removing the duplicate tags, DevOps successfully built the project.
I was googling for hours and never stumbled on this being the cause of the issue for anyone else. Hopefully this saves someone else some time in the future if they have the same problem.
For me, it was as simple as compiling a Windows IoT App with x86 platform instead of ARM.
In my case, this was happening on an Azure build.
I was able to resolve it by forcing the build to use Visual Studio 2019 tools.
I modified our build.cake file so that the MSBuild steps included the UseToolVersion for VS 2019 like this:
MSBuild(_solutionFile, settings => settings.SetConfiguration(_configuration)
.UseToolVersion(MSBuildToolVersion.VS2019));
The only thing that worked for me was to delete ALL project files and download them again from the version control. Then the problem disappeared.
If you are targeting Azure Service Fabric or other 64-bit environment, check that you have a consistent <PlatformTarget>x64</PlatformTarget> in all configurations defined in the CSPROJ file. In my case it built just fine locally but failed on the CI server because one of the many configurations had <PlatformTarget>AnyCPU</PlatformTarget>.
I was receiving the same error as the original poster, with Msbuild v15.9.21
Your project file doesn't list 'win' as a "RuntimeIdentifier". You should add 'win' to the "RuntimeIdentifiers" property in your project file and then re-run NuGet restore
My projects are .net Framework v4.6.2. The projects build fine locally using VS 2017, but failed when building on TeamCity Enterprise 10.0.5. I had recently converted my projects from .package to PackageReference - this causing the build to fail.
My solution was to add a new build step to explictly restore the solution's nuget packages before building the solution. It seems that before converting the projects to PackageReference this was being done on the build step implicitly.
I always get this error in the Azure pipeline. So far I have noticed the following fixed for me in various occasions:
1. do not commit the .suo file - if so, delete and recommit
2. do not commit the bin or obj folders - if so, delete and recommit
3. if there is a new project added, set the project dependency on the solution properties - save and commit the .sln file
I had same issue with one of the unit test project failing to compile after I upgraded to VS to 15.9.27 and the solution to delete the obj folder worked for me
A simple nuget restore before calling MSBuild worked for me. I have projects targeting .NET Framework 4.7.2 (not SDK Style, legacy style) which I migrated from packages.config syntax.
I experienced this issue with a MSBUILD project that I've added into a solution of VS2015 and VS2019, that project was compiled with VS2010. I just excluded it from solution and compiled it with VS2010, including the .DLL file into other projects that work with VS2015 and VS2019.
To projects mult-target fmk
Add this to your project file, for example:
<PropertyGroup>
<RuntimeIdentifier>ubuntu.16.04-x64</RuntimeIdentifier>
</PropertyGroup>
or
<PropertyGroup>
<RuntimeIdentifier>win</RuntimeIdentifier>
</PropertyGroup>
I'm using VS 2019 (16.11.17). I was working in 2022 on a different branch.
I tried all of these solutions and none worked, until I deleted the solution folder and cloned fresh.

Nuget packages doubled

I have a visual studio solution with several projects all specifing their own packages.config.
If I run "nuget restore blablabla.sln", I get e.g. grpc.core\1.11.0 in my packages folder.
If I let Visual Studio do this I will get grpc.core\1.11.0 and Grpc.Core.1.11.0 in my packages folder both with the same contents!?
Why is that?
BR,
Daniel
Nuget packages doubled
According to your description, you should have more than two package resources in your Visual Studio with same nuget package grpc.core\Grpc.Core (Ignore case). As we know, nuget is not case sensitive when searching and restoring packages. So:
Double check the packages grpc.core\1.11.0 and Grpc.Core.1.11.0 are the same except capitalization.
Clean up your \packages folder before restoring the nuget from
Visual Studio.
If you confirm the above, please check if your package feed have the nuget package grpc.core\1.11.0. You can remove it, since it have the same contents as package Grpc.Core.1.11.0 in the default package source nuegt.org.
Hope this helps.

Can't install local NuGet package

Details
Using Visual Studio 2017
Built NuGet package with NuGet Package Explorer
Placed .nupkg file in local folder on disk
Added folder to Package Sources in Visual Studio
I attempt to install the package using the Visual Studio GUI (Tools > NuGet Package Manager > Manage NuGet Packages for Solution...).
Problem
My package shows up in the list in the GUI, but when I click install, an error message says it can't find the package in the folder I put the .nupkg file in:
Package 'TDDeviceIntegration 1.0.0' is not found in the following primary source(s): 'C:\Users\j.smith\Documents\Visual Studio 2017\LocalNugetRepository\'. Please verify all your online package sources are available (OR) package id, version are specified correctly.
What I've tried
Putting the NuGet Package I've built in several different local folder locations and adding those to the Package Sources, all with the same result (it can't find the package I JUST put there).
I've restarted Visual Studio several times.
I've restarted my computer.
I've cleared my NuGet cache(s) from Visual Studio
Question
How do I diagnose this? How do I fix this? I just want to make sure that the NuGet package works locally before I give it to the rest of the team.
Thanks in advance!
How do I diagnose this? How do I fix this? I just want to make sure that the NuGet package works locally before I give it to the rest of the team.
Just as #orhtej2 comment, you should:
you rename it to TDDeviceIntegration.1.0.0.nupkg? (dot instead of
space between package name and version).
Additional, some info about why dot is really the only allowed package name-version separator.
That because namespace of nuget package follows a pattern similar to namespaces in .NET, using dot notation instead of hyphens.
You can get the source from following document:
Choosing a unique package identifier and setting the version number
Hope this helps.
According to this link from the NuGet GitHub Repository, you can possibly encounter this error when the version of your package is not "normalized", i.e. it's not made up of 4 digits.
Yours has 3 digits, so...
(and the last digit might have to be 0).

The nuget packages nightmare in VS 15.5.1

I have a solution with 15 projects. To better manage my references/dependencies, I have gathered all shared nuget packages in one .net core project. All projects requiring these packages have to reference it.
This works fine but it becomes a nightmare to update nuget packages.
Few days ago, a newer version of X.PagedList was released. After updatin the package, I got the following error messages
Assembly 'XXX' with identity 'XXX' uses 'X.PagedList v7.2.0 ...' which
has a higher version than referenced assembly 'X.PagedList' with
identity 'X.PagedList v7.1'
I tried to clean the solution, rebuild, remove/re-add the nuget package with no luck. I ended-up removing the nuget cache, restarting my computer and restoring all nuget packages... That can't be the easiest solution.
Earlier this month, I had similar issues. I was not getting an error, but it was like all my references were gone. All my import statements were detected as errors...
Am I the only one experiencing that kind of issues? Is there a way to make package update easier?
My environment:
Visual studio 2017 Community 15.5.1
ReSharper 2017.2.2
AWS Toolkit
1.) Delete the .vs directory in your solution folder or the folder above it. This is magic.
2.) Open the .config file in every project and delete all the binding redirects.
3.) Delete bin and obj folders for all projects.

NuGet packages not restore in visual studio 2017

I have Asp.netCore solution which was working fine on Visual Studio 2015 and then i moved to Visual Studio 2017. Now the problem is that in Visual Studio 2017 on every nuget packages there is yellow exclamation mark. Following are solution which i have tried so far.
I'm using Visual Studio Version: 15.3.1
Run as 'Administrator' and restore package.
Clear All Nugget Cache(s) from Tools > options > NuGet Package Manager > and again restore Nuget.
Note: I have searched and found following solution and tried but did not resolve my issue.
Solution 1
I found the answer on another thread here and credit should go to #AxelWass although he did not specifically focus it towards this, it absolutely fixes this issue. The above answer did not.
I had the same issue and solve it by opening the project in a text editor and deleting the following section:
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<PropertyGroup>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
</PropertyGroup>
<Error Condition="!Exists('..\packages\Microsoft.Net.Compilers.1.0.0\build\Microsoft.Net.Compilers.props')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\Microsoft.Net.Compilers.1.0.0\build\Microsoft.Net.Compilers.props'))" />
<Error Condition="!Exists('..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.0\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.0\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props'))" />
</Target>
Once this is removed, it will resolve this nightmare issue that VS2017 and PM seems to be unable to resolve. I too have run into this multiple times - especially when I blend many projects in the same solutions directory.
As mentioned in Microsoft Installing and reinstalling packages with package restore Documentation, you should Update-Package -reinstall:
Update-Package -reinstall -ProjectName <project> command where
is the name of the affected project as it appears in
Solution Explorer. Use Update-Package -reinstall by itself to restore
all packages in the solution.
If you still have the error, try edit your project file, check if there is A path refrence error there, also check the project/solution nuget config file.
By default, new installation of visual studio did not configure package source to search packages online. That caused the problem.
I found the answer with a little bit more work from a stackoverflow link: https://stackoverflow.com/a/32360953/1503372.
That answer mentions to use "https://www.nuget.org/api/v2" url to restore packages. When I opened the package manager console in visual studio 2017, I found it was searching for packages from my PC only (offline search).
I then added "https://www.nuget.org/api/v2" url as a source for restoring packages and it worked.
Follow below steps to add a package source.
Right click project > Manage nuget package and you will see "package source label".
Add highlighted URL to package source.
Select "All" as package source.
Once you have configured your visual studio to search for packages online, your all packages will be restored.
I discovered a wrong configuration in the nuget.config. I don't know why, in this file there are some exclusion for my current project.
You can see your global configuration running this command in File Explorer
%AppData%\NuGet\NuGet.Config