Develop Reference

How should I share the same NuGet package among multiple C# solutions?

I am working with Newtonsoft.Json (a.k.a. Json.net) now and multiple C# solutions need to reference it. Seems the most convenient and widely-used way is to install Newtonsoft.Json with NuGet package manager. But I find that the package is installed in the solution root directory (anyway, the installation is based on a given solution) and its size cannot just be neglected (a bit over 10M), so I wonder if there is an elegant way to share this package among different C# solutions.
I searched Google and found few satisfying results (maybe it's because I didn't express my requirement properly); the only sound answer is to create a .nuget folder both in the directory and in the solution and fill it with a NuGet.config file, as follows:
Create a .nuget folder in the root of the solution (by entering ".nuget.", actually)
Inside that folder, create a file NuGet.config.
In Visual Studio 2015, right click on the solution and add a new solution directory called “.nuget”
Right click on that folder and select to add an existing file and select the NuGet.config file created in (2).
Add content like this inside the NuGet.config file:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<solution>
<add key="disableSourceControlIntegration" value="true" />
</solution>
<config>
<add key="repositoryPath" value="E:\JsonExamples\C#Examples\UseJsonInCSharp\packages" />
</config>
</configuration>
Restart Visual Studio 2015.
But that didn't work because the using directive
using Newtonsoft.Json;
is still not recognized! Maybe there are something else that must be done, which isn't known to me but is common sense to veterans? Or perhaps this is because the version of the Newtonsoft.Json is too new for this to work? Can somebody help me? thanks a lot!
One more word: I'm currently using VS 2017, but I only found answers related to VS 2015, so I wonder the previous approach, if somehow works on VS 2015, will ever work for VS 2017.

Lets first clarify some things about NuGet and references in projects:
The job of references in project is to tell what external code this projects must look into - you can NOT go around this, you have to make a reference to Newtonsoft.Json in every project you want to use it.
The job of NuGet is to download/restore the nuget in some folder - the default "dumb" setting for old pre NuGet 4 versions is to make a seperate packages folder in every solution. Lets Focus on how to make this smarter.
Option 1 (Recommended) - Migrate everything to PackageReference
It is available since NuGet 4 in VS 2017+ (i recommend at least VS 2017 15.7+ which got wizard for automatic migration from older nuget versions). This is the most clean way of referencing NuGets since PackageReference in project does not hardcode NuGet download location. Instead it leaves this decision to local NuGet settings. By Default it is set to "%USERPROFILE%\.nuget\packages". No nuget package is duplicated, it acts as global cache for this computer. To force all new project to use PackageReference by default you must modify NuGet.config, here is how: Defaulting Package Management to PackageReference
Option 2 - specify common NuGet location for all project in the same repository
NuGet config settings are loaded per Solution. Having a common config file for NuGet is recommended even if you use PackageReference since download location is just one of many settings you might want to centrally manage for all Solutions (the other popular one is a setting which external NuGet repositories you want to use). NuGet download location setting is ignored by new PackageReference so it is safe to use it in mix scenario. VERY IMPORTANT, projects using this old NuGet use hardcoded reference to NuGet folder, so everytime you change this NuGet location setting you have to manually fix all NuGet references in your every project (by editing .csproj file manually or be deleting and re-adding NuGets), so chose wisely and do not change.
Details on how to correctly set global NuGet.config:
So first let me explain how shared NuGet.config settings work. NuGet scans all NuGet.config files from solution location up the hierarchy to root drive (it also check all .nuget folders). If multiple config files are detected it takes the one closest to solution. So for example you have "C:\Code\Repository1\Project1\Solution1.sln". If you want to have common NuGet settings for every solution in Repository1 put config file to a location like this "C:\Code\Repository1\NuGet.config". Also make sure this is the only config file inside whole Repository1 folder. Next step is to decide where to download all packages, for example "C:\Code\Repository1\NuGetPackages". To make everything work dynamically on all computers put relative path inside NuGet.config like this:
add key="repositoryPath" value="NuGetPackages"

Xamarin - Metadata file .../AWSSDK.SecurityToken.CodeAnalysis.dll could not be found

I am trying to implement offline sync functionality in my Xamarin App. I have installed the Nuget packages:
AWSSDK.SecurityToken
AWSSDK.SimpleDB
AWSSDK.CognitoSync
AWSSDK.CognitoIdentity
I am receiving this error when I try to rebuild my application
Severity Code Description Project File Line Suppression State
Error CS0006 Metadata file '..\..\packages\AWSSDK.SecurityToken.3.3.2\analyzers\dotnet\cs\AWSSDK.SecurityToken.CodeAnalysis.dll' could not be found

For me, I had to unload the errant project and edit the .csproj to have the correct path like so:
<ItemGroup>
<Analyzer Include="..\packages\AWSSDK.S3.3.3.10\analyzers\dotnet\cs\AWSSDK.S3.CodeAnalysis.dll" />
</ItemGroup>

I believe the problem is that the default AWS template that gets installed via the AWSToolkitPackage.vsix creates a reference to the code analyzer dll's as though a separate directory was created for the solution.
The simple fix is to eliminate one of the dots from where the file system references the NuGet package. I didn't have to close the solution or anything, simply open up the affected project file (likely *.csproj) in your favorite text editor and find the package reference.
Bad:
..\packages\AWSSDK.EC2.3.3.19\analyzers\dotnet\cs\AWSSDK.EC2.CodeAnalysis.dll
Works for me:
.\packages\AWSSDK.EC2.3.3.19\analyzers\dotnet\cs\AWSSDK.EC2.CodeAnalysis.dll
In my case there were three separate packages that needed to have their paths corrected. Note that once I upgraded to the latest versions of "awssdk" NuGet packages the analyzers themselves were removed from the project's reference.
That makes me think the alternate solution is to simply update all the NuGet package references and don't worry about editing the csproj file.

C# visual studio how to relocate nuget package folder?

I hired a contractor to do some coding for me. He setup nuget.config in the solution folder with the following repository path:
<configuration>
<solution>
<add key="disableSourceControlIntegration"
value="true" />
</solution>
<config>
<add key="repositoryPath"
value="../lib" />
</config>
</configuration>
And I'm not too happy about his decision: this will place the nuget package folder outside the solution folder. I can easily change the repository path, simply by setting:
value="../<mySolutionFolder>/lib" />
However when I do this a curious thing happens: every single reference that I use in my solution is now broken. And nothing that I change in the .csproj files or other *.config files will allow my projects to find their references.
The only workaround is to re-create each project in my solution by starting from scratch, and add->existing items, etc. and reference->manage nuget packages, and install every reference again.
I have many projects in my solution and performing this for every one is understandably time consuming.
I would like to know if there is an easy way?
It seems like there should be a way for Nuget and VS to play nicely so that I can easily move the repository folder to a different path location.

One way to fix the reference paths is to use the Package Manager Console.
From the Package Manager Console you can run the following command to reinstall the NuGet packages which will fix the hint paths for the references.
Update-Package -reinstall
This will reinstall all NuGet packages in the solution. I am assuming you have the code under source control so you can see what changes are made to the projects if you need to revert them after this reinstall.
There is more documentation on reinstalling NuGet packages on the NuGet documentation site.
Another way to fix this is to do a find and replace in the .csproj files to fix the hint path.

I encountered this problem when I moved the actual folders around in my solution. I usually do a find/replace with VS Code looking for >..\packages\ and replace it with >..\..\packages\. This time I did the following:
Perform Update-Package -Reinstall
this worked for everything with hint paths
does not work when your project uses NuGet packages to build your project because there are custom MSBuild statements that need to be manually fixed, see next step.
Edit the .csproj files manually that do not build, in my example:
<Import Project="..\..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.8\build\net45\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props" Condition="Exists('..\..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.8\build\net45\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" />
<Import Project="..\..\packages\Microsoft.Net.Compilers.2.4.0\build\Microsoft.Net.Compilers.props" Condition="Exists('..\..\packages\Microsoft.Net.Compilers.2.4.0\build\Microsoft.Net.Compilers.props')" />
Notice that there are 2 condition statements in the <Import> that use relative pathing to ..\..\packages.
Hopefully these steps will help someone else.

Package.config is used for put file somewhere else from the folder, it help best to not upload package unusually when you add something in your project through Nuget.
Try to copy the package to that folder (new path you set) or simply close the project, open it again and click on Restore after going to Manage project reference.

After trying all solutions posted here I could not escape one primary issue: references to non nuget items, such as System and System.Core remained invalid (yellow triangle listed next to them). Removing them and adding them did not make them valid again. Further (as we all know) Visual Studio is terrible and giving reasons for why a reference is considered invalid.
So while Matt's solution does indeed relocate the nuget package folder, the solution in not left in a working state. Further, updating hint paths did not help because those are specific to the nuget packages. I cannot explain why basic references suchas System also become invalid. Perhaps someone reading this a year from now can leave a message with an explanation.
What I ended up doing is rebuilding my entire project without a nuget.config file (I deleted it). This causes nuget to use all defaults. Downloaded packages get stored in \\<solution_folder>\packages\. After the solution was working again, I added back the nuget.config file but with the following removed:
<config>
<add key="repositoryPath"
value="../lib" />
</config>
...and removing that section causes nuget to rely on default behavior which turns out to be exactly what I wanted (installing packages to \packages, etc).
If anyone else is about to undertake this laborious effort, I found this SO solution helpful for moving folders and files from the old solution to the new one.

I managed to do this to my own solution without realising how (and ended up with a packages folder at the *.sln level and another one at The level below that) - but I'm pretty sure now that this all has to do with migrating from using a packages config file, to the new method of using package references. This can occur if you use a newer version of visual studio (which is possibly what your contractor did) or via a button/commend in NuGet, or via a right-click context menu.
One of the things that happens is the creation of a 'global' packages folder (the one at .sln level) which is meant to save your space since it means you can have multiple solutions using the same package without having huge duplicate package folders repeated in every solution.
I found this out when I was merging The text is two csproj files and needed to Google: import project difference to package reference
See https://learn.microsoft.com/en-us/nuget/reference/migrate-packages-config-to-package-reference

What happened to all my references?

Scenario: I have 14 projects (each in their own folder in TFS) with an additional folder named AllSolutions to contain all of them. Note not everyone on the team needs all 14 projects this is why I put the AllSolution.sln in its own folder.
The Allsolutions.sln was just upgraded to Nuget 2.0 and it compiles fine! So far so good.
I also have sub-solutions (that contain only those projects they need). These solutions are contained in the root folder shown below as ...Framework...
Problem
Any of the sub-solutions I load show this (whether they have one or more projects) all show missing assemblies:
I suspect that my AllSolutions.sln gobbled them up. Perhaps I need to move all these solutions to the AllSolutions folder? BTW there is nothing that shows up in the output window when I open these sub-solutions.
If I open/edit any of the Proj files this is what I see.
Notice that the Nuget work put in hint paths at the AllSolutions folder.. Do I have to put in Hint paths for all of these and why?

In NuGet 2.0 or in the packages.config world, there is a package folder per solution. The issue you are seeing is due to this. NuGet 2.0 inserts a hint path during package install in the project file pointing to this location. You would need to resolve the relative location for this to work. You can also choose to use the repository path property in NuGet.config to provide a common location for the packages folder. This should solve your problem.
Instead of upgrading to NuGet 2.0, if you are using Visual Studio 2015 and above, I would recommend that you consider moving to project.json. In the porject.json world, you can have a global packages folder and your project file is not modified during package install. For more information on this, check out the wiki entry here

checking ASP.net webAPI out using TFS with GIT into different directory causes missing directive or assembly reference errors

I had a ASP.net 4.5 webAPI that worked well that was located in C:\users\me\source\MyProject .
I then needed to push this project to a new Git Repo in Visual studio online.
to push it there I did the following
git remote add origin https://my-cool-webAPI.visualstudio.com/DefaultCollection/_git/MYcoolProject
git push -u origin --all
Everything appeared to be fine.
So i then cloned this project from the Visual Studio Online TFS Git repo to a new source directory.
It was in C:/users/me/source/MyProject and I moved it to C:\Users\me\Desktop\Source\MyProject
Now I have 166 errors and 166 warnings complaining about assembly references.
Here is more detail on a specific error.
Any idea what I did wrong?
** it looks like my references are out of wack, Notice it doesnt know the path to find Entity-Framework.
Is this because I didnt check in the Packages folder or something else
How do I refresh them? and How does one ensure they make it to source control, ie are they managed by a certain file similar to say a Rails Gemfile?
Currently I am doing the following steps to try and run my WebAPI that had no errors before I moved it to this new repo.
Clean the solution (that succeeds)
Build the solution (166 errors and 166 warnings)

Bateloche was on the money with his comments
In order to fix this I had to do the following.
I had to delete my packages folder.
Make sure your packages folder wasnt checked in by default its in the gitignore file that visual studio by defuault generates so it shouldnt be check in.
in VS goto Tools -> NuGet Package Manager -> settings and enabable Nuget to download missing packages.
Make sure to open the package manager console and click accept to refresh the nuget packages. The gotcha was that you may have to restart visual studio for this to work