We Keep Coding

Managing Nuget packages for C# project present in multiple solutions

I am now on the phase of refactoring madness of a big project which has a lot of legacy and unstable modules. I've decided to split the solution that currently has ALL projects (so around 20 and there will be more because of unit test projects that would surely come in next months) chained in it to make it more independent and granular.
With this approach there are modules e.g. API clients that needs to be either referenced or added in multiple solutions.
The problem is that Nuget packages are getting restored only on the solution that it was added originally for the first time. So the simplest example:
Solution A:
------ ProjectA
------ APIClient
Solution B:
------ ProjectB
------ APIClient
Since we are not including packages folder it causes problems with Nuget packages:
Clone the repo.
Open Solution B, build it and restore the Nugets for solution.
Errors with packages of ClientAPI in Solution B.
Go to Solution A build it and restore the Nugets for solution
Get back to Solution B.
Nugets are restored for ClientAPI in Solution B and errors are gone.
Is there a way to somehow:
Make the project using different path for each solution?
Maybe chain solutions in build to make Solution A always build with Solution B? But that sounds like loosing some benefits of splitting this one big solution to smaller ones.
Use any other approach to make it more granular and yet do not suffer problems with the necessity of rebuilding all? I've heard of private Nuget feeds, would that be an answer to this problem if my config allows that?
My config:
VCS: TFS with TFVC
IDE: Visual Studio Proffesional 2017
Default package management format: Packages.config

Managing Nuget packages for C# project present in multiple solutions
Thanks for you reply. I have reproduced this issue with two solutions, SolutionA with Project APIClient. And SolutionB, add the existing project APIClient in the SolutionA to the SolutionB.
Then if we restore the nuget package on the SolutionB, package in the project APIClient in the SolutionB will be restored in the \packages folder in the SolutionB folder by default rather than in the SolutionA folder.
In this case, the project APIClient still missing the .dll reference in the SolutionB, you still have to go to SolutionA and restore the nuget packages. That the reason why you got that issue.
To resolve this issue, you could add a NuGet.Config file next to the SolutionA and SolutionB with the following content:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<config>
<add key="repositoryPath" value="C:\Packages" />
</config>
</configuration>
So, the \packages folder not related to the solution file.
Besides, if you are interested, you can try to convert the packages.config to the packagereference for the project APIClient, with this setting, the nuget package will be saved in the global packages folder, C:\Users\<UserName>\.nuget\packages.
Hope this helps.

Why do you not add package in the solution B ?
What package mode do you use ?
If you use "Package reference" mode, you must add package information in csproj of solution B.
If you use "Package config" mode, you must add package information in package.config file of solution B.

MsBuild does not find restored NuGet-Packages on Visual Studio Online

I try to build a solution stored in an external GIT-Repository on Visual Studio Online.
It has the following steps:
1: Git Restore - Works
2: NuGet Restore - Works
3: Build - Does NOT work
My first guess when looking at the logs is that MsBuild is not looking for the Packages where NuGet had stored them.
Some Lines from NuGet Restore:
2018-03-14T21:10:11.0352862Z Completed installation of AngleSharp 0.9.9
2018-03-14T21:10:11.0353230Z Adding package 'AngleSharp.0.9.9' to folder 'D:\a\1\s\packages'
2018-03-14T21:10:11.0353563Z Added package 'AngleSharp.0.9.9' to folder 'D:\a\1\s\packages'
2018-03-14T21:10:11.0354972Z Added package 'AngleSharp.0.9.9' to folder 'D:\a\1\s\packages' from source 'https://api.nuget.org/v3/index.json' 'Microsoft.SharePointOnline.CSOM.16.1.7317.1200' to folder 'D:\a\1\s\packages'
Some lines from MsBuild:
018-03-14T21:10:21.2105399Z PrepareForBuild:
2018-03-14T21:10:21.2105793Z Creating directory "bin\Release\".
2018-03-14T21:10:21.2424947Z Creating directory "obj\Release\".
2018-03-14T21:10:30.3569560Z ResolveAssemblyReferences:
2018-03-14T21:10:30.3570425Z Primary reference "AngleSharp, Version=0.9.9.0, Culture=neutral, PublicKeyToken=e83494dcdc6d31ea, processorArchitecture=MSIL".
2018-03-14T21:10:30.3670272Z ##[warning]C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(2041,5): Warning MSB3245: Could not resolve this reference. Could not locate the assembly "AngleSharp, Version=0.9.9.0, Culture=neutral, PublicKeyToken=e83494dcdc6d31ea, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
My solution/packages structure is:
....\mysolution\myproject\myproject.csproj
....\mysolution\myproject\packages.config
Current Config:
So how can I change the Nuget and/or msbuild-behavior to make this work?
(Update): To clear this up: I have this problem with every package. They all are in the packages.config, each one is downloaded from Nuget, but each one also isn't found from MsBuild
(Update2) The Commands generated are currently the following:
NUGET:
D:\a\_tool\NuGet\4.4.1\x64\nuget.exe restore D:\a\1\s\AweCsomeO365\packages.config -PackagesDirectory D:\a\1\a\packages -Verbosity Detailed -NonInteractive -ConfigFile D:\a\1\Nuget\tempNuGet_22.config
MSBUILD:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\msbuild.exe" "D:\a\1\s\AweCsomeO365\AweCsomeO365.csproj" /nologo /nr:false /dl:CentralLogger,"D:\a\_tasks\VSBuild_(GUID)\1.126.0\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll";"RootDetailId=(GUID)|SolutionDir=D:\a\1\s\AweCsomeO365"*ForwardingLogger,"D:\a\_tasks\VSBuild_(GUID)\1.126.0\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll" /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation=D:\a\1\a /p:ReferencePath=D:\a\1\a\packages /p:platform="anyCPU" /p:configuration="Release" /p:VisualStudioVersion="15.0" /p:_MSDeployUserAgent="VSTS_(GUID)_build_4_22
I replaced the GUIDs; tempNuGetConfig is something that seems to be generated by VSTS dynamically
Still. even if the log states that nuget stores the packages
Added package 'AngleSharp.0.9.9' to folder 'D:\a\1\a\packages'
MsBuild does not seem to find them there:
For SearchPath "D:\a\1\a\packages".
2018-03-16T13:57:42.4625155Z Considered "D:\a\1\a\packages\AngleSharp.winmd", but it didn't exist.
2018-03-16T13:57:42.4625456Z Considered "D:\a\1\a\packages\AngleSharp.dll", but it didn't exist.
2018-03-16T13:57:42.4625730Z Considered "D:\a\1\a\packages\AngleSharp.exe", but it didn't exist.
VSTS-Configurationvalues:
MsBuild: /p:ReferencePath=$(Build.StagingDirectory)\packages
Nuget-DestiantionDirectory: $(Build.StagingDirectory)\packages
(update3): I have no solution file, but only a csproj-file in that repository

The issue was that inside the project there was a hintpath for the packages directing to a location that was not within the GIT-Repository (and shouldn't):
<Reference Include="AngleSharp, Version=0.9.9.0, Culture=neutral, PublicKeyToken=e83494dcdc6d31ea, processorArchitecture=MSIL">
<HintPath>..\..\AweCsome365Test\packages\AngleSharp.0.9.9\lib\net45\AngleSharp.dll</HintPath>
</Reference>
My original approach was to define a target directory to NuGet and a Source Directory for MSBuild to use another location to the packages that both understand.
The issue though (as far as I understand) is, that NuGet always creates a subfolder-structure "./packages/{PackagesName}/lib/net45/{file}" and MSBuild does not look recursivly when setting "./packages" as source path.
The above is just an explanation for the future guy running into the same problem
So my solution was to mimic the local behavior for nuget and changing the output directory to match the HintPath (even if there is no "AweCsome365Test")-directory in the repository:
(I will leave this question open as this solution smells fishy. If anyone has a better solution that allows to chain nuget and msbuild without using the HintPath I am happily willing to spend my bounty on it)

I believe that your MSBuild "ReferencePath" parameter is not correct. you are telling MS Build that all your references (nuget packages and their dlls included) are going to be located at "D:\a\1\a\packages" but that is not where nuget will download and store the packages and dlls. Nuget will download and extract files into D:\a\1\a\packages\{packageName}\{version}\lib\{environment}\package.dll. I think you need to remove that last parameter (ReferencePath) from your MSBuild arguments.
I also noticed that your PackageLocation parameter is not the same as the destination for the NuGet restore task, do you need to add the "\packages" to that parameter like the destination in the restore task?

Change the nuget restore destination directory to $(Build.SourcesDirectory)\packages and remove the msbuild ReferencePath parameter.

The answers here are largely right. However it's worth noting another cause that can result in this behaviour. My toolchain was using Azure DevOps which is basically the same as Visual Studio Online, just a few years later.
Cause:
Reference your project from a different solution (cross-repo), for instance for debugging purposes
Update NuGet references in the problematic project from the external place you referenced it from
What this does is make use of the solution location for packages when the package gets installed.
For .Net core/standard projects, using Update-Package -reinstall appears to fix things. However, for .Net Framework projects, even though packages.json may get rebuilt, the <HintPath /> node in the .csproj gets left as is - with a reference to a packages folder that Azure will never create.
Simple fix:
Right click on the offending solutions locally, and choose Unload
Right click on the unloaded project, choose edit .csproj
Find any hintpaths that look like ../../OtherRepo/packages (the slash in use may vary), and change them to ../packages
Confirm the solution does build locally still
Push the changes to Azure, and cross your fingers
This approach will fix the issue caused by consolidating / updating packages from the wrong place rather than requiring a change to the build pipeline to spoof that location (which in may case, wasn't working very well either).

Why can't Visual Studio find this nuget package's .props file?

Due to some git project changes, when I try to build, I get an error:
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 ..\packages\MSTest.TestAdapter.1.1.11\build\net45\MSTest.TestAdapter.props.
The references to the project contain four missing references, two of which Microsoft.VisualStudio.TestPlatform.TestFramework, and Microsoft.VisualStudio.TestPlatform.TestFramework.Extensions which seem to be related.
The other two, in case it proves to be relevant are System, and System.Core, but they aren't causing any problems... which is weird, cause I'm definately using them.
That missing file, the one from the error message, is absolutely there.
I've tried to uninstall and reinstall both packages, but nothing seems to help.

Open the projects .csproj file with your favourite text editor and delete any references to
MSTest.TestAdapter.props.
Edit: This is safe to do so, all that happened is that you have removed the DLL but for one reason or another your project file still references it as a dependency.

I would modify #JoshuaDuxbury's answer to say: you need to clean out obsolete references to MSTest.TestAdapter.props.
In my case, I had just updated the MSTest.TestAdapter NuGet fronm 1.3.2 to 2.0.0, but apparently when I did that, Visual Studio didn't clean up my .csproj file perfectly.
So, I had to delete the superflous MSTest.TestAdapter.props highlighted in two places:
Near the top of the project file:
...and again at the bottom of the file:
Once I did that, my CI pipeline was able to build everything correctly again.
Some of you with sharp eyes may notice something funny w/the 1.3.2 of MSTest.TestAdapter shown above: it seems the path to the packages folder is off! But that would be a topic for a different thread (or maybe an alternate explanation to why your build pipeline is unhappy.. maybe just fix your path to packages).

My issue didn't occur on my development box but on the Azure Build Pipeline. I removed the offending props files as per the other answers but to no avail. Ultimately I had to add the Nuget restore step to my the Azure build pipeline and move it to the proper slot before the building:

I have no idea how I've done it but I've had the same error and I thought the files were here but they actually weren't... so anyone who has this issue double check the paths.
In my case the Packages folder was at the same level as the project file however it was looking for files in the parent directory. Nuget restore and Update-Package -reinstall
were not fixing anything.

Include NuGet packages in TeamCity

I recently started using NuGet to manage external packages. For now I have only needed it for NLog.
Everything works fine when I Build the project in VS 2012. However, I am trying out TeamCity as a CI server (I'm fairly new to CI) and it is giving me the following error:
[Csc] SomeNamespace\SomeClass.cs(10, 7): error CS0246:
The type or namespace name 'NLog' could not be found
(are you missing a using directive or an assembly reference?)
(this error is repeated throughout where ever I use NLog)
Now I did not include the 'packages/' folder in SVN, since I thought it was good practice not to include binaries and let MSBuild in TeamCity download these on its own. However it's clearly not doing that. I DO include the 'packages.xml' file in SVN.
What can I check to see what is going wrong?
Update
Thanks to #DavidBrabant I was nudged in the right direction. However, I now get the following error in TeamCity:
Package restore is disabled by default. To give consent, open the Visual Studio Options dialog,
click on Package Manager node and check 'Allow NuGet to download missing packages during build.'
However I'm not in Visual Studio but TeamCity, so I do not know how to set 'consent' to true! I tried to set RestorePackages to 'true' in the NuGet.targets file:
<RestorePackages Condition=" '$(RestorePackages)' == '' ">true</RestorePackages>
but this didn't work.
Update 2
To make it work I also set the following property NuGet.targets:
<RequireRestoreConsent Condition=" '$(RequireRestoreConsent)' != 'true' ">false</RequireRestoreConsent>
This made the build run succesfully!

The enable package restore feature built into NuGet allows you to very easily set up the pre-build part of the workflow. To do so, right-click the solution node in Visual Studio’s Solution Explorer, and click the Enable NuGet Package Restore option. Note that you need to have the NuGet Visual Studio Extension installed on your system. If you do, and you still don’t see this menu item appear, you either already enabled this option, or you have a folder named .nuget in your solution directory.
After having set that option, you can now delete all sub-folders of your package installation directory, by default $(SolutionDir)\packages, except for the repositories.config file, and your solution should still compile properly. During compilation, you should see NuGet installation traces in the Visual Studio output window, and you should see the required NuGet packages reappear in the package installation directory as well.
Also see Using Nuget without committing packages.

Just to reiterate on update 2. If you stumbled here looking for a quick fix to TeamCity not downloading NuGet packages, try changing this line
<RequireRestoreConsent Condition=" '$(RequireRestoreConsent)' != 'false' ">true</RequireRestoreConsent>
to this line
<RequireRestoreConsent Condition=" '$(RequireRestoreConsent)' != 'true' ">false</RequireRestoreConsent>
in your NuGet.targets file and it should work.

In TeamCity v8 I was able to solve the "restore package" error using an environment variable in TC.
See:
http://johanleino.wordpress.com/2013/03/19/using-teamcity-for-asp-net-development-part-2/
and
http://confluence.jetbrains.com/display/TCD7/Configuring+Build+Parameters#ConfiguringBuildParameters-SystemPropertiesandEnvironmentVariables
Setting env.EnableNuGetPackageRestore to "true" as an environment variable at the project level will fix the problem for all build configurations. Feels a little bit better doing this than editing the NuGet.targets file imho.

Take a look at this post: http://johanleino.wordpress.com/2013/06/17/making-use-of-teamcitys-nuget-capabilities-part-2/
As described there I added first build step "NuGet Installer", made some coinfiguration and now packages are automatically restored.

The referenced component 'EntityFramework' could not be found.

So im downloading a project at home from work over team foundation server. I download the project and it won't compile because of the error. Warning 2 The referenced component 'EntityFramework' could not be found. Could anyone offer guidance in how I can get entity framework to work. I installed nuget package.
Thankyou

I suggest you to check:
1) "Allow NuGet to download missing packages during build" ticked
Tool --> Options... --> Package Manager --> General
2) "Project selected" ticked
Solution Explorer --> right-click on the solution/project --> Manage NuPackages
3) Rebuild Solution
EDIT
For completeness I would like to add that if you are working with a CI system (e.g. Jenkins) or you are using MSBuild on the command line, you need to select Enable NuGet Package Restore to make it work:
Enable NuGet Package Restore http://docs.nuget.org/docs/Workflows/images/enable-package-restore.png

I had the same problem. I solved it like this:
Choose References > Right-click > Add Reference ...
Choose Browse tab
Find your Project Folder > packages > EntityFramework.4.1.10331.0 > lib
Choose EntityFramework.dll
Click OK

This happened to me, after I moved projects to a subfolder.
Then, the relative paths to the packages folder were not correct anymore.
Got errors like that:
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 ..\packages\NETStandard.Library.2.0.1\build\netstandard2.0\NETStandard.Library.targets. PROJECTNAME D:\VSTS\TEAMPROJECT\src\PROJECTFOLDER\PROJECTNAME.csproj
Fixed it by editing the *.csproj file and corrected the relative paths, in my case from ..\packages to ..\..\packages
Also make sure to check the paths under
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">

There are good ways suggested by the developers, you may also try this solution to solve your problem.
In your case your project has a reference to the EntityFramework library, but library it self is not available to you project. You may try either the following:
If you have NuGet package manager:
Click on Project-> Manage NuGet Packages. It will open following window.
Find the EntityFramework and click Install.
- Alternatively, Download the EntityFramework library to your computer, then
Right-Click the Prject-> Add References...-> Browse-> Locate your
EntityFramework library-> Click OK
- Optionally you may use package manager to install library reference, check this link package-manager-console (Note: This might require NuGet Package manager)

I solved this issue by adding Entity Framework reference (Add ref) under C:\ Prog Files\Entity...\Binaries\Entity Framework.dll into my project. Hope this helps!

An old thread, but for anyone that this may help..
What worked for me was to go to the 'Packages' folder in the root of my solution and delete the EntityFramework.6.4.4 folder.
Then, go to Manage Nuget Packages menu option, and this banner pops up:
After pressing Restore the missing reference was restored.