I have my project set to Allow NuGet to download missing packages as well as Automatically check for missing packages during build in Visual Studio. In my solution folder, there is a packages folder and it contains everything that I need for my project. However the references to them in the project are still broken.
I have tried removing the references and adding them with NuGet, but NuGet says the item is already in the project (it is in the packages folder) even though the reference is there and the project can't build. The only way that I can seem to get around it is to manually go into each of the packages in the packages folder and select every .dll.
Is there a better way to do this?
Open package manager console and type:
Update-Package -Reinstall
This should refresh all your references based on each project's packages.config file.
Related
References (specifically from internal nuget server) seem to be unresolved after using restore nuget packages. The project builds fine but anything that uses these references show as errors in the code until you manually expand references and click it (shows a warning on the reference, when clicked it resolves and removes warning).
Is there an easy way to auto resolve them without going through every project and clicking the refrerence manually?
Is there an easy way to auto resolve them without going through every project and clicking the refrerence manually?
Please try to use the NuGet command line in the Package Manager Console:
Update-Package -reinstall
to force reinstall the package references into project.
NuGet Restore only restores files in the packages directory (\packages folder ), but does not restore files inside your project or otherwise modify your project.
Check the similar issue for some more details.
After I restore nugget packages my solution builds but intellisense says the references don't exist and I get what looks like errors but are false positive. This only seems to happen in my test projects. The only way I have found to fix it is to go into the references for each project that reports errors and view the properties. Once I open one the broken reference in the properties window all of the broken references for that project magically get fixed.
Just to be clear - the restore is working - its just VS doesn't think so; it puts the missing reference icon on the reference and intellisense reports errors on any code that uses the reference. It all builds and runs fine
nuget references appear missing after restore but aren't
You need use the NuGet command line in the Package Manager Console:
Update-Package -reinstall
to force reinstall the package references into project after restore nuget package.
NuGet Restore only restores files in the packages directory (\packages folder ), but does not restore files inside your project or otherwise modify your project, in other words, NuGet will not reinstall the package references in the project. After you restore the packages, the packages are re-download to the packages directory, so the package references are broken temporary, then the intellisense reports missing reference errors on any code that uses the references.
To resolve this question, you can use the "Update-Package -reinstall" command to force reinstall the package references, after that, all references are reinstalled, this weird behavior will disappear.
Hope this can help you.
I'm training 5 people on using Visual Studio. They've mapped their drives and have "downloaded" the solution from TFS which contains 10 projects. All located at the same depth in TFS folder structure. When the new folks download the solution there's one project that doesn't get the NUGET references even though the Package folder (created by NUGET) is at the same depth of the other 10 projects when viewed in TFS.
We know how to add these manually but is there a way to automatically have VS do it? Why would only one project lose it's reference with the Package Folder right there?
It seems you are still using MSBuild-Integrated package restore approach. If NuGet recognizes that the MSBuild-Integrated package restore approach is enabled for the solution, Automatic Package Restore is skipped.
You need to migrating MSBuild-Integrated solutions to use Automatic Package Restore, then the packages will be restored automatically.
In addition, you need to update you NuGet manager to the latest version in VS Tools--Extensions and Updates. And make sure Visual Studio is configured to 'Allow NuGet to download missing packages' and 'Automatically check for missing packages during build in Visual Studio' in VS Tools--Options--NuGet Package Mnager--General.
To Fix:
Unload all projects first, then right click and select edit project.
Find this line:
<Import Project="$(SolutionDir)\.nuget\nuget.targets" />
Comment it out.
Reload all the projects and compile.
This applies to Nuget api version 2.
Note you may configure all projects for Nuget at the solution level.
The package manager for the solution presents a set of check boxes for every project along with the buttons (Install or Uninstall).
In my projects folder root, I have a packages folder that is utilized by various web applications at C:/Projects/packages. All application references that point to this folder work fine.
However, with a new application, when I pulled the latest code, all references expect the packages folder to live at the solution level - C:/Projects/CompanyName/Apps/SolutionFolder/packages.
When I pull latest, this folder is not included (it's never checked in to subversion) so I have missing references when I first open a project up. However, when I try to build, it doesn't pull the latest for these packages and of course, doesn't compile. When I run Update-Package -reinstall, it will update the packages IN C:/Projects/packages, and it WILL NOT create the packages folder at the solution level.
I've confirmed that I have the packages.config in each project in the solution and that each project expects that the assemblies will be housed in the packages folder at that level. What's weird is that after I run the -reinstall, these hintpaths in the project files will actually point to the C:/Projects/packages folder and the assembly references will resolve...but only for 3rd party packages and NOT for our in-house built packages.
Does anyone know why this occurs? The solution has been to get a copy of the packages folder that a coworker is using and paste that into the solution folder but that doesn't solve the problem if it occurs again.
Per #MattWards link I checked the nuget.config file in appdata, which specified this C:/project.packages path. After removing this setting and building my solution, the packages folder was added to the solution level and everything worked.
When other developers get the vs.net 2013 solution from TFS, Nuget doesn't seem to work as expected and many of the individual projects in the solution do not have the required dll's downloaded (although they are defined in the packages.config file).
If I go to view the installed packages, it shows up as they are installed and the correct projects are selected.
I went into console and ran:
Update-Package -Reinstall
After doing this, my packages.config file was truncated for whatever reason and 80% of my packages were removed from the config file!
What should I be looking into as it is either I have setup the solution incorrectly or nuget just isn't reliable.
Thoughts?
First of all make sure that NuGet Packages Restore is turned ON.
This forces to restore missing binaries directly from NuGet server. You can right click on Solution and enable this option as follow:
Make sure that .nuget folder that contains nuget.exe is created under your Solution.
You'll want to make sure that you have automatic package restore turned on in VS 2013. You can do this in the options.
Then, when you build, VS should grab the packages for you. If you want to manually restore the packages or do it from powershell, you'll want to use the command nuget.exe restore in the folder your solution lives in.
If you're using custom package sources, you'll want to make sure you specified them in your nuget.config file.