Cake NuGetRestore Could not locate nuget.exe - nuget

I have created simple .NET5 console application which can be successfully run using "dotnet restore" and "dotnet run". Application is using one package Newtonsoft.Json.
I want to restore NuGet packages using NuGetRestore() but in result I get "Could not locate nuget.exe".
I am using Cake .NET Tool in version 1.1.0 and default configuration.
As far as I remember, previously when I was using Cake before version 1.0.0 nuget.exe was downloaded to 'tools' folder.
What am I missing? How to make sure nuget.exe is downloaded/provided by Cake?

In order for the NuGet tool to be downloaded to the tools folder, you need to include the NuGet.CommandLine package in your Cake build script. e.g.
#tool nuget:?package=NuGet.CommandLine&version=5.9.1
Related info:
Example build.cake file referencing NuGet.CommandLine
NuGet.exe related documentation

Cake itself never did download nuget.exe. The example bootstrapper for Cake Runner for .NET Framework does this in certain conditions. Example bootstrapper for Cake .NET Tool does not download nuget.exe and you need to make yourself sure to have it available, either by updating the bootstrapper, using the tool prepocessor directive in your build script, or any other mechanism outside of Cake.

Related

"No executable" when using dotnet add

I'm trying to add a Nuget .core package using
dotnet add package [package name]
but get "No executable found matching command dotnet-add". I've installed Nuget and can use "dotnet" to create applications, restore, build, run, etc.
What am I doing wrong? Thanks.
The dotnet add family of verbs was released in version 1.0.0 of the dotnet cli tooling and is not part of the 1.0.0-preview2-* range of versions previously used for project.json projects.
This means that dotnet add verbs are only available for msbuild based projects (=> .csproj).

Native binaries in NuGet package installed into DNX project

I've created NuGet package containing native x86 binaries. Binaries are copying to bin directory by MSBuild script from this answer.
But this approach does not work with DNX projects (ASP.NET 5 web app for example), because MSBuild script is not installing. So I have FileNotFoundException.
How to make it alive?
Solution for me was to make runtimes\win\native directory in NuGet package structure, as described here: https://docs.nuget.org/Create/uwp-create
In runtime DNX adds this directory to PATH variable, so managed dll can load it.

OctoPack failing in TFS Build

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

Using nuget to update project files outside of Package Manager Console

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.

NuGet and nUnit automation

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.