Permanently remove machine-wide package source - visual-studio

I've recently uninstalled Service Fabric and its SDK from my machine. However, it has left behind a machine-wide package source:
Microsoft Azure Service Fabric SDK
C:\Program Files\Microsoft SDKs\Service Fabric\packages
This folder no longer exists. It is causing my build to fail. Unticking this option as an available source doesn't seem to persist between sessions.
How can I permanently remove this package source?
UPDATE
In the Visual Studio options, delete is not available for this package source. I can untick it, but that doesn't seem to be persistent.
My NuGet.config doesn't reference it either. I can't find another NuGet.config on my computer.
%AppData%\NuGet\NuGet.config
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
<add key="Microsoft Visual Studio Offline Packages" value="C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\" />
</packageSources>
<packageRestore>
<add key="enabled" value="True" />
<add key="automatic" value="True" />
</packageRestore>
<bindingRedirects>
<add key="skip" value="False" />
</bindingRedirects>
<packageManagement>
<add key="format" value="0" />
<add key="disabled" value="False" />
</packageManagement>
</configuration>

I found that deleting this file (as an Administrator) solved the problem. It must have been missed by the Service Fabric uninstaller.
C:\Program Files (x86)\NuGet\Config\ServiceFabricSDK.config

just delete unwanted .config files in C:\Program Files (x86)\NuGet\Config

I had this same issue on an Azure Devops build machine, which was causing a build failure when it would build locally and on other build machines. Found this file here: C:\Program Files (x86)\NuGet\Config\nuget.config which contained the offending packages.
deleted the nuget.config file at that location and worked like a charm. Hope this helps someone.

How can I permanently remove this package source?
When we create Service Fabric application with Visual Studio, we always receive following message in the output window:
An error occurred attempting to configure NuGet to reference the
Service Fabric SDK package location as a package source. To fix this,
you can manually add a NuGet package source in the Options window and
setting it to the following path: C:\Program Files\Microsoft
SDKs\Service Fabric\packages.
You may configure nuget setting as suggestion.
So, to permanently remove this package source, you can open the visual Studio Tools->NuGet Package Manager->Package Manager settings->Package Source:
Select that nuget package source and delete it. Or you can open the configuration file nuget.config directly from path C:\Users\<UserName>\AppData\Roaming\NuGet\nuget.config and delete it:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
...
<add key="Test" value="C:\Program Files\Microsoft SDKs\Service Fabric\packages" />
</packageSources>
<packageRestore>
<add key="enabled" value="True" />
<add key="automatic" value="True" />
</packageRestore>
...
</configuration>
Move the package source <add key="Test" value="C:\Program Files\Microsoft SDKs\Service Fabric\packages" />.
Hope this helps.

Related

VS2017 nuget keeps searching for packages in wrong location

So I migrated from nuget packages.config to PackageReference and found out there were some compatibility issues. I reverted the project to its working state (before the PackageReference) and now my project is not compiling.
I get the following error:
Severity Code Description Project File Line Suppression State
Error The package EntityFramework with version 6.2.0 could not be found in C:\Users\user.nuget\packages. Run a NuGet package restore to download the package. DbManager
This happened to multiple packages. It seems that Nuget is searching for packages in the user.net\package directory for some reason. Originally, there was a folder within the project that contained all the packages.
I forced the global path to be at the folder within the project by editing the NuGet.Config file.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<config>
<add key="repositoryPath" value="C:\Projects\App\App Source\packages\" />
<add key="globalPackagesFolder" value="C:\Projects\App\App Source\packages\" />
</config>
<packageSources>
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
</packageSources>
<packageRestore>
<add key="enabled" value="True" />
<add key="automatic" value="True" />
</packageRestore>
<bindingRedirects>
<add key="skip" value="False" />
</bindingRedirects>
</configuration>
I don't know why Nuget keeps looking for packages at that location. It should be looking at the packages folder within the project.
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="EntityFramework" version="6.2.0" targetFramework="net46" />
<package id="EntityFramework6.Npgsql" version="3.1.1" targetFramework="net46" />
<package id="Npgsql" version="3.2.7" targetFramework="net46" />
<package id="System.Threading.Tasks.Extensions" version="4.3.0" targetFramework="net46" />
<package id="Z.EntityFramework.Plus.EF6" version="1.7.17" targetFramework="net46" />
</packages>
All of these packages in packages.config are not being found. This problem started happening when I tried PackageReference.
Is there any way to reset Nuget's settings? I would appreciate any guidance in solving this problem.
TLDR; This is caused by latent copies of the new project.assets.json file being left in your /obj/ folders. These can be safely deleted.
You can run this Powershell (at your own risk) in your root solution folder as a quick way to purge these files:
ls project.assets.json -Recurse | foreach {rm $_}
project.assets.json is generated for projects using PackageReference to cache the Nuget dependency graph for your project. It seems to confuse Visual Studio/Nuget if it's left there even if your project is using (or reverted back to using) packages.config
This can happen in Visual Studio 2019 as well, if you try PackageReference and then revert back to packages.config (or even if you switch between Git branches with one Nuget restore method versus the other).
Further Info
More info on project.assets.json here:
https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-build?tabs=netcore2x

NuGet fails to find package if it's not in Cache

I have an internal feed setup for NuGet. When I try to build one of my projects (via a TFS build server), I get an error that NuGet cannot find version xxx of package yyy.
I go to the NuGet package folder on the server and the correct package/version is there. However, the package/version does not exist in the NuGet cache folder:
C:\Users[user account]\AppData\Local\NuGet\Cache
If I copy the correct package/version to this cache folder, then the build succeeds.
Any ideas?
Possible duplicate with NuGet fails to find existing package . If there are some service issues related to search and package restore functionality. It is possible cause of your package restore failure.
If there is a cached version of this package, NuGet will access there and the restore will be working fine.
The solution is updating your nugget to the latest version (At least 3.4+) You can also refer a similar issue in GitHub: Package restore intermittently fails with "Unable to find version 'x' of package 'y'"
Check Nuget.config in your Project. It should have the path to the Source that is your NuGet package folder on the server should be present in the nuget.config file.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<solution>
<add key="disableSourceControlIntegration" value="true" />
</solution>
<packageRestore>
<!-- Allow NuGet to download missing packages -->
<add key="enabled" value="True" />
<!-- Automatically check for missing packages during build in Visual Studio -->
<add key="automatic" value="True" />
</packageRestore>
<activePackageSource>
<!-- this tells that all of them are active -->
<add key="All" value="(Aggregate source)" />
</activePackageSource>
<packageSources>
<add key="PrivatePackages" value="\\TestPath\nuget" />
</packageSources>
</configuration>

Installing NuGet package with dependencies on multiple sources

My job has a private NuGet repo. I'm able to install packages from it and from nuget.org. I'm running into problems when there's a package stored on the private repo that has a dependency on a package hosted on nuget.org.
For instance, my private repo hosts a package, P1. P1 has a dependency on P2 which is hosted on nuget.org. If do an "install-package P1" with my private repo set as the source i'll get an error saying it couldn't find the dependency P2. This makes sense since it's looking for P2 in the private repo but it's hosted on nuget.org. So far the workaround has been installing P2 from nuget.org then installing P1 from the private repo. While this technically works it's tedious and going to make selling NuGet to the rest of the team difficult.
Is there anyway I can run install-package with multiple sources? I've tried passing a list into the -Source parameter but so far have gotten
The NuGet.config is being managed by visual studio so any changes I make to it are being wiped out every time a run a nuget command in Visual Studio. I tried adding an additional nuget.config file at the solution level but as far as I can tell it was being ignored. I've tried several visitations of the install=package command but they generally look something like this:
Install-Package P1 -Source https://api.nuget.org/v3/index.json,http://privatefeed.com
For reference here is the NuGet.config file but changing it seems futile.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageRestore>
<add key="enabled" value="True" />
<add key="automatic" value="True" />
</packageRestore>
<packageSources>
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
<add key="Private Nuget" value="http://privatefeed.com" />
</packageSources>
<disabledPackageSources>
<add key="Microsoft and .NET" value="true" />
</disabledPackageSources>
<activePackageSource>
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
</activePackageSource>
</configuration>
Using NuGet.exe, you can repeat the -Source option to specify multiple package sources.
Example:
nuget install P1 -Source https://api.nuget.org/v3/index.json -Source http://privatefeed.com
It appears that it's impossible to specify multiple sources using the Package Manage Console (PowerShell). However, if no -Source is specified then a NuGet.Config file is used. The config file can have multiple package sources and the file itself can be shared with a team.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
<add key="Private Nuget" value="http://privatefeed.com" />
</packageSources>
</configuration>
Save as NuGet.Config in the same directory as your solution and add it to version control.
Note that you might have to reload visual studio for the config changes to take effect.
Now you can install packages without configuring -Source.
Example:
Install-Package P1

NuGet and VS2013 ignoring packageSourceCredentials in nuget.config

I have a private nuget server which I am trying to pull packages from (eventually Azure build agent but I am trying this locally first).
I am using the 2.7 NuGet meaning I do not need .NuGet folder (along with .exe and .targets). I have a nuget.config in my solution directory.
I know the nuget.config is being picked up, as it locates my remote repository but the credentials supplied in the config are not used.
Here is my config:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<activePackageSource>
<add key="All" value="(Aggregate source)" />
</activePackageSource>
<packageSources>
<add key="https://www.nuget.org/api/v2/" value="https://www.nuget.org/api/v2/" />
<add key="myrepo" value="http://myrepo:81/nuget/myfeed" />
</packageSources>
<disabledPackageSources />
<packageSourceCredentials>
<myrepo>
<add key="Username" value="user" />
<add key="ClearTextPassword" value="pass" />
</myrepo>
</packageSourceCredentials>
</configuration>
What would cause nuget to ignore these credentials? I have checked with Fiddler and no credentials are being sent, and the server responds with a 401 (correctly):
Error 1 NuGet Package restore failed for project MyProject: The remote server returned an error: (401) Unauthorized.. 0 0
Use the 'Manage NuGet Packages' dialog !
Do not rely on building/rebuilding in Visual Studio expecting that it will restore the missing packages. Open the 'Manage NuGet Packages' for a project (right click on a failing project and choose the option) and you will see a message "Some packages are missing for this project..." with a 'Restore' button. Restoring using that button will resolve these authentication issues.

NuGet Package custom package path

I want NuGet to automatically download missing packages to a packages location outside of the solution 'globalpackages' folder. I have amended the NuGet.Config file as per [this help page][1].
My solutions's NuGet.Config file:
<configuration>
<solution>
<!-- Disable source control integration of packages folder -->
<add key="disableSourceControlIntegration" value="true" />
</solution>
<config>
<!-- Repository packages folder path -->
<add key="repositoryPath" value="$\..\..\globalpackages" />
</config>
<packageRestore>
<!-- Allow NuGet to download missing packages -->
<add key="enabled" value="True" />
<!-- Automatically check for missing packages during build in Visual Studio -->
<add key="automatic" value="True" />
</packageRestore>
</configuration>
When looking in a project's .csproj file, the following references still exist:
<Reference Include="C5">
<HintPath>..\packages\C5.2.2.5073.27396\lib\portable-net40+sl50+wp80+win\C5.dll</HintPath>
</Reference>
This is pointing to the wrong folder. Do I need to hard-update each of these references for each project?
I am using Visual Studio 2013 and NuGet 2.8
Do not hard update each of the NuGet references. Just delete them and add the packages again.

Resources