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.
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
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
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.
I am building an MVC4 web application with VS2012 professional with NuGet Package Manager version 2.2.31210. I have multiple projects in my solution, all sharing various packages I installed using NuGet. One of my projects is an MVC4 web application where I am using packages such as bootstrap, jquery UI, etc, all installed using NuGet.
When I clone a fresh copy of my entire solution from my repository and build my MVC4 project, the package restore feature seems to be working: it creates the packages directory under the solution direcotry and populates it will all the versions of the packages I expect to see. However, the content files do not get copied to the appropriate places in the MVC app directory. The weird thing is that it does create directories for the content, but does not copy the content files themselves.
For example, I am using the Twitter Bootstrap package which appears in the packages/Twitter.Bootstrap.2.2.2. In the MVC project a directory called bootstrap (containing css, img, and js directories) gets created in the Content directory. But, no css or js files are copied into those directories!
Does anyone have a clue what magic incantation I must utter to get the build to copy these content files from the NuGet packages directory?
This is a very common issue we are all having. I've created an MSBuild Task NugetContentRestoreTask that will do this trick for you. Run the following command in the Package Manager Console:
Install Nuget Content Restore MSBuild Targets
PM> Install-Package MSBuild.NugetContentRestore
The only thing left is to call it from your BeforeBuild Target with something like this:
Project File Targets
<Target Name="BeforeBuild">
<NugetContentRestoreTask SolutionDir="$(SolutionDir)" ProjectDir="$(ProjectDir)" />
</Target>
You can take a look at the source repo and find it on nuget.org
Additional Content Folders
This nuget only includes the default folders scripts, images, fonts, and content, it is not a recursive directory includes. For additional content subfolders - you must assign the property AdditionalFolders.
<Target Name="BeforeBuild">
<NugetContentRestoreTask SolutionDir="$(SolutionDir)" ProjectDir="$(ProjectDir)"
AdditionalFolders="less;sass;common" />
</Target>
I have found a workaround, but it is ugly. By executing the following command in the NuGet Package Manager Console: Update-Package -Reinstall all the files are indeed copied to their proper places within the Mvc project Content and Scripts directories.
Unfortunately, this is risky because you are likely to end up with the wrong versions of certain packages. For example, in my case after the command finishes executing (which takes quite a while by the way), I end up with jQuery version 1.4.4. This is way old, and I assume it must be an explicit dependency of some other package that is being updated. So it appears that the order in which the packages actually get updated by NuGet is significant (it does not appear to parse the entire dependency tree for all packages and pick only the latest versions from the union of all dependencies, which seems like it would be the preferred behavior). Rather, as the command executes I see it replacing the jQuery package several times with different versions as it works its way through all the packages and their dependencies, only to end up with a very old version.
A similar approach is the execute the Update-Package -Reinstall command explicitly for each package that is causing my problem, but this is incredibly tedious and error prone.
The NuGet Package Restore feature should yield the same result as manually executing the Install-Package or Update-Package -Reinstall command for a package, but it does not.
I don't like to have the thirdparty JavaScript files under source control either. Thats why I've followed Jeff Handley advice in http://nuget.codeplex.com/workitem/2094 to create a solution my self. I didn't go the executable way, but created a nuget solution level package which does the trick.
http://www.nuget.org/packages/Baseclass.Contrib.Nuget.GitIgnoreContent/
It's tied to git, as it automatically updates the .gitignore file.
Short description:
Ignore nuget content files in git:
Generate entries in the .gitignore file to exclude nuget content files from the source repository
Restore nuget content files before building (Automatically in VS and manually with a powershell script
I've written a blog post describing how to use it.
http://www.baseclass.ch/blog/Lists/Beitraege/Post.aspx?ID=9&mobile=0
In Visual Studio 2015 Update 1, they now support contentFiles. The caveat with this is that it only works in projects that use project.json.
In reference to the problem that you are having, there is a good blog post that explains why you see this behaviour: NuGet Package Restore Common Misconceptions.
For my projects it turned out that content files work with PackageReferences only:
Existing project with nuget references via packages.config
Installed NuGet package with content files
Build project
No content files in output directory
Conversion of packages.config to PackageReferences
Build project
Content files have been copied to output directory
IDE is Visual Studio 2017. The project is an application project which means it is in the old csproj format.
I have a VS project and in the project properties under the Debug tab I set:
Start External Program: D:\SolutionName\packages\NUnit.2.5.10.11092\tools\nunit.exe
Command Arguments: projectname.dll
This lets me start nUnit and run the nunits tests dll and when I start debugging the project.
Is there a better way? We use TFS and not everyone installs the solution to d: and the version number in the path where NuGet installs it changes periodically.
Was hoping to some how grab the text of the nunit.exe path from the path in the VS: Project : References section that was placed there by NuGet. This way I wouldn't have to change it for nUnit version changes and other TFS users wouldn't have to change it either.
Any ideas?
You might want to take a look at this:
http://lostechies.com/joshuaflanagan/2011/06/24/how-to-use-a-tool-installed-by-nuget-in-your-build-scripts/
If you're using NUnit in NuGet, then the runner will be in packages\NUnit(version)\, so you could probably use $(SolutionDir)packages\NUnit(blah) in the External Program command to run the version pulled from the NuGet package.
As Danny mentioned, install it to a relative (to your source code) tools folder via NuGet, ie
./tools/nuget.exe install Nunit.Runners -o ./tools
Then in your project configuration, just use the relative path.
I ran into the same issue. After a great deal of searching I found this question: Get NuGet package folder in MSBuild
Basically, you can create a project item containing a sort-of "wildcard" in the path name in place of the specific version number and then tell MSBuild to retrieve the relative path directory.