I have a Visual Studio, C# solution with several projects. Some of those point to older versions of some packages. my local nuget repo has more current, stable versions. e.g.
What I want to do is update all those old 3.0.246-alpha references to the latest stable version, 3.1.0
What is the best way to do that?
Output window after clicking Install:
errors at top of screen:
This is what I want to fix. There is no version 3.0.246 of that module, so I want Nuget to overide it with latest stable version, 3.1
Due to the limitation, I post this as an answer, but may include some comments.(Sorry for that)
As I searched online(nuget.org), I found no packages called TBSM.*, perhaps they were created by yourself/your company… and just used(saved) locally?
From the error message, it reported that the NuGet package was not found on source XXXXX, so did you perform some operations to remove the old version of the NuGet packages? (Maybe also removed the NuGet cache files?)
I did some tests:
Since I don’t know the specific structures of your projects/NuGet Package, I just created two NuGet packages for test locally with same names(ID) and different versions, and then added the package source path to the settings, and installed the first NuGet package into one project, after that deleted this NuGet package and the cache files. Then tried to Update it, NuGet Package manager could still update it to the latest version successfully, even if I uncheck these options: Allow NuGet to download missing packages and Automatically check for missing packages during build in Visual Studio from VS > Tools > Options > NuGet Package Manager > General.
Of course, I may not remove all of the NuGet packages’ cache files, or the issue is cause by the specific NuGet packages’ structures(cause I used two NuGet packages, but yours maybe used the same one with something updated)…
What I suggest:
1). If it is possible, you can have a try Uninstall and then Install the relates version.(remember to make a backup before this)
2). Try to select this two options in VS(Tools > Options > NuGet Package Manager > General), “Allow NuGet to download missing packages” and “Automatically check for missing packages during build in Visual Studio”, and then click Clear All NuGet Cache(s) button. Make sure you have added the right path source from VS > Tools > Options > NuGet Package Manager > Package Sources and try to install/update the NuGet packages again.(Generally, clear cache will not cause errors, but please remember to make a backup before clearing cache)
In the project I've been using some custom NuGet sources. Apparently some of them are no longer available but I do have the newer (and only newer) versions of the packages on the other (still working) server. Is there a way to restore the packages directly to the newest versions without manually replacing all the references in the .csproj and packages.config files?
I've tried running Updade-Package -Reinstall but I only get the following error message:
Some NuGet packages are missing from the solution. The packages need to be restored in order to build the dependency graph. Restore the packages before performing any operations.
If some packages you use (and still want to use) are no longer available, I suggest you to make a backup of them.
Find the Nuget cache on your server. On Windows this is located at
%userprofile%.nuget\packages
Spot the packages (and version) you want to backup and copy the .nupkg files in their respective folders.
Then you have two choices:
Create a private Nuget feed
Create a local Nuget feed on your development machine
The 1st option has the advantage to be a single source that can be used on any machine you want (development machine, build server...etc) but you will have more set-up, especially for the authentication/authorization (because it's a private feed)
For the 2nd option: Simply create a C:/Nuget folder and put any .nupkg you want.
Then in Visual Studio go to:
Tools -> Nuget Package Manager -> Package Manager Settings -> Package Sources
Click on the green + button to add a new source, simply give it the name Local and browse to your C:/Nuget to set the source.
From now on when you want to restore your Nuget packages, Visual Studio will first look into the nuget.org feed and if it doesn't find the referenced packages, will then look into your Local feed and cache the installed package to the %userprofile%.nuget\packages of your machine.
I hope that answer to your question, I was not quite sure about what you asked and your knowledge about Nuget.
UPDATE:
I think I understand your question better now.
First of all, I think your misunderstand the Update-Package -Reinstall command. It will reinstall the packages with the SAME version as already referenced but simply reinstalling them. It's a useful command for example when you change the target framework of your project. Then you can reinstall the same versions of the packages and they will retarget this .NET Framework version.
So if a nuget restore isn't working then Update-Package -Reinstall will obviously fail too.
With Nuget, when something isn't working, you shouldn't insist but instead, find the tweak that will make it working again. I can't count how many times I went to the different caches to delete some cached packages.
I think you should try to use nuget restore and see what packages are causing issues, then uninstall these packages (this will just remove the reference from the .csproj and packages.config if they aren't installed in the project yet), then you can finally install the newest version of these packages.
I'm trying to use nopCommerce(Which is written in .NET Core) but when I want to run the project I face 52 Errors telling me Run a nuget package restore
Assets file ~\obj\project.assets.json' not found. Run a NuGet package restore to generate this file. Nop.Web.MVC.Testsote
when I use the right click on the solution and selecting Restore Nuget Packages I get this message:
All packages are already installed and there is nothing to restore.
but those 52 Errors are still there and in Tools -> NuGet Package Manager -> Manage NuGet Packages for Solution there is nothing installed on the solution,also I Recently updated my VS2017 to 15.5.4
To fix this error from Tools > NuGet Package Manager > Package Manager Console simply run:
dotnet restore
The error occurs because the dotnet cli does not create the all of the required files initially. Doing dotnet restore adds the required files.
In my case the error was the GIT repository. It had spaces in the name, making my project unable to restore
If this is your issue, just rename the GIT repository when you clone
git clone http://Your%20Project%20With%20Spaces newprojectname
In case when 'dotnet restore' not works, following steps may help:
Visual Studio >> Tools >> Options >> Nuget Manager >> Package Sources
Unchecked any third party package sources.
Rebuild solution.
To those with the same issue as me in Azure DevOps / VSTS environment encountering a similar message:
C:\Program Files\dotnet\sdk\2.2.104\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(208,5): Error NETSDK1004: Assets file '...\obj\project.assets.json' not found. Run a NuGet package restore to generate this file
Add /t:Restore to your MSBuild Arguments in Build Solution.
Closing and re-opening Visual Studio solved this issue for me, once I had made sure the NuGet packages had been restored as per other answers posted here.
Edit: Sometimes just trying to build again fixes the problem.
For me when i did - dotnet restore still error was occurring.
I went to
1 Tool -> NuGet Package Maneger -> Package Manager settings -> click on "Clear all NuGet Cache(s)"
2 dotnet restore
resolved issues.
In visual studio 2017 please do following steps:
1) select Tool=>Options=>NuGet Package Manager=> Package Sources then uncheck Microsoft Visual Studio Offline Packages Option.
2) now open Tool=>NuGet Package Maneger=>Package Manager Console.
3) execute command in PM>dotnet restore.
Hope its working...
It was mentioned earlier but I just wanted to re-emphasize the importance of not have space anywhere in your pathing! This is what was getting me. You've been warned.
If this error occurs as part of a build in Azure DevOps (TFS) and your build already has a NuGet restore task, this error may indicate the NuGet restore task was not able to restore all packages, especially if you use a custom package source (such as an internal NuGet server). Adding /t:Restore;Build to the MSBuild Arguments seems to be one way to resolve the error, but this asks MSBuild to perform an additional NuGet restore operation. I believe this succeeds because MSBuild uses the custom package source configured in Visual Studio. A preferable solution is to fix the NuGet restore task.
To configure a custom package source for the NuGet restore task:
Create a NuGet.config file that lists all of the package sources (Microsoft Visual Studio Offline Packages, nuget.org, and your custom package source) and add it to source control.
In the Nuget restore task under Feeds to use: select the option Feeds in my NuGet.config.
Provide the path to NuGet.config.
Remove the /t:Restore;Build option from the MSBuild task.
Additional information is available here.
For me I upgraded NuGet.exe from 3.4 to 4.9 because 3.4 doesn't understand how to restore packages for .NET Core.
For details please see dotnet restore vs. nuget restore with teamcity
You will get required packages from "https://api.nuget.org/v3/index.json". Add this in Package Resources. Also make sure other packages are unchecked for time being. And Click Restore Nuget Package on Solution Explorer
Select Tools > NuGet Package Manager > Package Manager Console
And then Run:
dotnet restore <project or solution name>
Solved by adding /t:Restore;Build to MSBuild Arguments
Nothing above worked for me. But simply deleting all 'bin' and 'obj' folders did the trick.
You can go for : Tools > NuGet Package Manager > Package Manager Console
And then Run:
dotnet restore
little late to the answer but seems this will add value. Looking at the error - it seems to occur in CI/CD pipeline.
Just running "dotnet build" will be sufficient enough.
dotnet build
dotnet build runs the "restore" by default.
I lost several hours on this error in Azure DevOps when I set the 'Visual Studio Build' task in a build pipeline to build an individual project in my solution, rather than the whole solution.
Doing that means that DevOps either doesn't build any (or possibly some, I'm not sure which) of the projects referenced by the project you've targeted for the build, and therefore those projects won't have their project.json.asset files generated, which then causes this issue.
The solution for me was to swap from using the VS Build task to the MSBuild task. Using the MSBuild task for an individual project correctly builds any projects referenced by the project you're building and eliminates this error.
This problem happening when your build tool is not set to do restore on projects set to use PackageReference vs packages.config and mostly affect Net Core and Netstandard new style projects.
When you open Visual Studio and build, it resolves this for you. But if you use automation, CLI tools, you see this issue.
Many solutions are offered here. But all you need to remember, you need to force restore. In some instances you use dotnet restore before build. If you build using MsBuild just add /t:Restore switch to your command.
Bottom line, you need to see why restoring can't be activated. Either bad nuget source or missing restore action, or outdated nuget.exe, or all of the above.
If simply restoring NuGet packages does not work make sure in Tools -> Options -> NuGet Package Manager -> General under Package Restore that the "Allow NuGet to download missing packages" is checked.
Then Restore NuGet Packages again OR just REBUILD after deleting obj and bin folders.
run your VS as administrator after that in package manager console run dotnet restore.
When using VSTS, check your global.json file. I had entered the sdk version as just "2.2" which caused a parse error (but not when building locally). Adding the full version, "2.2.104" solved the problem.
I have same problem and dotnet resotre not work for me. I Install this component:
and the run dotnet resotre and the problem has solved.
In my case, I had the following added to my *.csproj files to fully remove obj and bin folders on 'Clean'. Apparently, it was the culprit. Got rid of that and viola, all started to work again. Now I'm using the "Clean Bin" extension instead. Hope this might help anyone who is running into this issue, and none of the mentioned fixes works.
<Target Name="SuperClean" AfterTargets="Clean">
<!-- Remove obj folder -->
<RemoveDir Directories="$(BaseIntermediateOutputPath)" />
<!-- Remove bin folder -->
<RemoveDir Directories="$(BaseOutputPath)" />
</Target>
Another one, if by any chance you're using Dropbox, check for Conflicted in file names, do a search in your repo and delete all those conflicted files.
This may have happened if you have moved the files around.
Cause of this defect: you have to remove the injected Nuget in file explorer.
Solution: Once you remove that Nuget in your system, then remove from following location.
select Tool=>Options=>NuGet Package Manager=> Package Sources then uncheck Microsoft Visual Studio Offline Packages Option
This worked for me:
added this package source:
Microsoft and .net
https://www.nuget.org/api/v2/curated-feeds/microsoftdotnet/
then run "dotnet restore" in the console
In my case I had a problem with the Available Package Sources. I had move the local nuget repository folder to a new path but I did not update it in the Nuget Available Package Sources. When I've correct the path issue, update it in the Available Package Sources and after that everything (nuget restor, etc) was working fine.
Very weird experience I have encountered!
I had cloned with GIT bash and GIT cmd-Line earlier, I encountered the above issues.
Later, I cloned with Tortoise-GIT and everything worked as expected.
May be this is a crazy answer, but trying with this once may save your time!
Seen this after adding a WinForms Core 3.1 project (from project templates) on VS-2019 vs 16.4.0 and trying to run it out of the box. Clean or Rebuild the entire solution did not work.
I just reloaded my solution.. that is File/Close Solution and then reopening it and rebuilding it solved the problem.
For me it turned out to be a nuget source credentials problem. I had recently changed my password for accessing a nexus server and visual studio was still using the old password when trying to access a nuget on that server through the windows credential manager. To fix it, I had to delete the entry for those outdated credentials in the credential manager and after, when I did a nuget restore, it prompted me for a password letting me enter the new password, which got saved in the credential manager again. You can access the credential manager from the cmd line using CmdKey.exe.
I'm using Visual Studio Online with Visual Studio 2013. The build fails with
You are trying to build with OctoPack, but the NuGet targets file that OctoPack depends on is not available on this computer. This is probably because the OctoPack package has not been committed to source control, or NuGet Package Restore is not enabled
According to this link https://octopusdeploy.com/blog/octopack-3.0 I need to make some changes to get package restore working properly, but another link within the previous one says that no configuration is required if using VS2013 and Visual Studio Online Nuget.org
When I build in VS all of the packages get restored first and then the project builds. Also if I build the project and invoke Octopack via command line everything works fine. Thoughts?
If you do run NuGet Package Restore before building, this should work. However, make sure the path in your project file referring to OctoPack.targets is correct - you might have moved your packages folder or the project file and the relative paths no longer match. Easiest way to fix it would be to run Update-Package -Reinstall Octopack.
NuGet Package Restore was recently changed so you wouldn't need to include NuGet in the solution to do a package restore. However, OctoPack still needs NuGet on the path so it can find it. You can try explicitly specifying the path to NuGet by adding this parameter when calling OctoPack.
/p:OctoPackNuGetExePath=<path>\nuget.exe
You just need to check in the Octopack targets file.
\packages\OctoPack.2.0.26\targets\OctoPack.targets
Nuget.exe only supports managing packages at a file system/configuration level. The powershell commands command the magic that update the .proj files.
With that said, i need the ability to update a csproj file with the latest version of a NuGet package outside of visual studio (automated).
Basically, how do I use Install-Package (or any of the other methods) inside of an external powershell script of my own?
UPDATE:
I would like to ability to add project references outside of VS for the following reason.
My company has a lot of shared libraries that depend on each other in some cases. I am using TFS Nugetter to build and publish nuget packages from TFS. I want to ensure that the developers can't queue a build (package) unless the project can build and run on all the newer versions. This ensures that all the newer versions of the libraries work with all the newer versions of its dependencies. If the build fails, then you need to update your nuget reference in VS and fix the compiler errors/unit tests.
I have been looking at the NuGet source and I think I found an easy way to reuse NuGet source to modify proj files outside of VS (kinda).
System.Type t = System.Type.GetTypeFromProgID("VisualStudio.DTE.10.0", true);
var dte = (DTE)System.Activator.CreateInstance(t, true);
dte.Solution.Open(
#"C:\Users\paul.knopf\Documents\Visual Studio 2010\Projects\SLNMemory\SLNMemory.sln");
Basically, open an in-memory version of visual studio, run the nuget commands, then save.
In a build step, after GetWorkspace, I would like to run this in-memory vs to update all nuget references to the latest version.
What do you think? It would definitely be slow, but we would be on the same code base and have all the functionality we need.
Automating Visual Studio as you describe is certainly a possibility.
Another way I looked at was using SharpDevelop to install NuGet packages outside of Visual Studio. The NuGet PowerShell cmdlets were modified to accept a solution and you could automate installation, including the use of PowerShell scripts in a NuGet package, from the command line. The code has not been updated so it targets an old version of NuGet but could be updated. Again this is similar to your solution and fairly heavyweight solution.