So, the error I'm getting when my build server builds my project is:
Package restore is disabled by default. To give consent, open the
Visual Studio Options dialog.
I'm aware of what this error means and how to resolve it. The problem is I cannot change anything on the build server - my company won't allow it. Additionally, creating an environment variable called EnableNuGetPackageRestore and setting it to true is not an option because that involves modifying the build server.
My question is: is it possible to simply check all of the NuGet packages that are part of a solution into source control so then the build server won't have any reason to go out and re-download them? If so, then perhaps you could explain why this error is still happening, when I've verified that all of the NuGet packages (.nupkg) are in the packages folder in source control:
Second Question: Forgive my ignorance, but what is the reason for the "package restore" feature? Is it to ensure that each package is up to date with the latest version of that package? It seems to me that this "feature" should be a setting that shouldn't hinder building a project on a build server. In my mind, if we want the build server to look for newer packages, then sure, do it, otherwise if I have all my packages in source control and we tell the build server somehow to NOT look for newer packages, that sounds reasonable to me.
So, my situation specifically was I downloaded the source code for the actual Nuget site (to create an internal implementation of Nuget in my company), and when I tried to deploy it, that's when I got the error above.
What I had to do was:
Delete the .nuget folder.
Within your file system (not via Visual Studio), modify the .csproj files (delete where it said <packageRestore>true</packageRestore>, as well as where it imported the project that had nuget.targets in the line - just do a "find" for "nuget.targets", and delete all lines that have an import.
Save your .csproj file changes.
Check in your changes into TFS.
Deploy your solution.
Related
I cloned .NET 5 project, which should be working (unfortunately, I can't provide the project so you could reproduce the problem). I didn't change anything, I just wanted to build it, however, I am getting this error when restoring packages (although the project itself is on different disk, I found out that this is "global-packages" folder):
Could not find a part of the path 'C:\Users\me\.nuget\packages\microsoft.aspnetcore.azureappservices.siteextension\5.0.5\content\store\x64\net5.0\microsoft.extensions.configuration.environmentvariables\5.0.0\lib\netstandard2.0\Microsoft.Extensions.Configuration.EnvironmentVariables.dll'
However, I don't think it is a problem with this particular dll, as my colleague cloned the same project and he is getting the same error, but with different library.
This is what I've already tried doing:
Clearing all nuget cache
Checking "automatically check for missing packages during build in visual studio"
Updating everything I could (VS, nuget..)
Running VS as Administrator
Checking package sources (yes, nuget.org is there)
Adding "add key="repositoryPath" value="$..\..\packages"" into the nuget.config file - this didn't actually create the package folder in the defined path
Clean/rebuild/... everything
I think, that the problem will be in some setting, but I have no idea, where to look :/
Use the command dotnet restore
instead of
dotnet nuget
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.
My CruiseControl.NET build server is not able to restore the nuget packages of my projects. According to some websites it should be enough to set the environment variable EnableNuGetPackageRestore to "true" and restarted Cruise Control after that, but that didn't help in my case.
What else can I do?
Do i need to install something that "enables" Nuget?
I noticed I have a .nuget folder in C:\Users\MyUser\ but I don't have this folder on the build server. Is this required? Who created that on my pc? Visual Studio?
Without seeing the project config, I am assuming you are using either a Microsoft Solution or project, and are building from that using the msbuild task in CC.net. If so, your Solution needs a .nuget folder structure (in the same location as the sln/prj file there needs to be a .nuget folder, inside that folder, you need a NuGet.Config and a NuGet.exe as well as a NuGet.targets).
This should be automatically added to your solution if you right click on it inside visual studio and select "Enable nuget Package Restore".
You can find more information # Nuget Documentation. There is quite a few ways to skin this cat, but, based on your initial statement, you are just missing the .nuget folder in your Solution, and once added it should just work. Otherwise, you have to look at pre-build tasks, and that gets a little more detailed than is usually necessary.
What can I do to fix this build? Entity Framework was added to this project via NuGet.
All projects compile without issues on local system. But the build fails on Visual Studio Online.
By turning on Diagnostic logging, I am able to trace to this warning which makes my builds failed:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets(1605,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "EntityFramework.SqlServer". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
DO NOT right-click the project and chose "Enable NuGet Package Restore". This is the "old way" of doing package restores as per the Nuget Docs.
Package restoration should happen as part of the build process by default. If it's not (which seems to be the case), you've got a different problem, but there's not enough information to say what.
I am able to resolve this error simply by right clicking at the solution in Solution Explorer and select Enable NuGet Package Restore.
That adds a few more files to my solution and modify a few project files. The build server can then restore the packages at build time and is happy in the end.
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