NuGet and nUnit automation - nunit

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.

Related

CruiseControl.NET NuGet not working

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.

Get current version of package outside of Visual Studio

We are migrating over to using packages and NuGet for managing our dependencies on 3rd party components. This works well when referencing packages from within Visual Studio or building on the build server via msbuild.
However there are a number of files that we would like to access in our build scripts and installers. Previously these would be in source control with a well known path, now as the version of the package that we are consuming changes so the path to the package and hence the files is changing.
Is there a simple way I can get the path to a given package? The best solution I currently have is to search for all packages.config files and extract the package version from them.
Examples of the files that we need to access are
The NUnit console executable from the NUnit.Runners package for running unit tests.
License files from various packages that we redistribute with our installer.
Using the packages.config file is a pretty good solution. NuGet itself uses two approaches:
Reading the package information from the packages.config and using that to resolve to the packages path.
Enumerating all the directories in the packages directory.
You could use NuGet.Core to do either of the above if you do not want to write the code yourself. The classes that can be used are the DefaultPackagePathResolver, the PackageReferenceFile and LocalPackageRepository or SharedPackageRepository.
One problem with the second approach is that sometimes NuGet may occasionally leave behind NuGet packages that are not necessarily referenced by a project. In that case looking at the package directories may give you the incorrect information.
The only other approach I can think of might be to read the project files looking for the assembly references. Although that would not work for a solution level package such as NUnit.Runners.

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

Copy tools from nuget package to bin folder

I have some automated tests that are using Selenium WebDriver. Tests should run on Chrome so I need to have ChromeDriver.exe. I am using NuGet to download the libraries and found that the ChromeDriver could be downloaded as a package too (http://www.nuget.org/packages/WebDriver.ChromeDriver).
However, this package contains only ChromeDriver.exe in the Tools folder. I need to copy this file into the bin folder because tests need to find it. Is there some way to do the copy in a generic way (without specific paths), because in the folder where the ChromeDriver.exe is unpacked from package contains version number so I would need to change the paths when the new version will be used. Also I would need to do similar thing with the NUnit.Runner package.
You could probably use a post-build event. Then inside the event use copy/xcopy and move it into the bin folder after the project has successfully built.

NuGet package files not being copied to project content during build

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.