I've created a branch v0.8 where there is mostly a java code. Thanks OData4j we implemented the the NuGet Feed in Java and thus I decided to remove stale .NET code from build and repository. We bundle builds from this branch in TeamCity 7.1 EAP builds. Still, builds are binary compatible with TeamCity 7.0, so you can give it a try there as well.
Remember the time NuGet 1.7 was released. As it turned out, TeamCity provided NuGet feed was not aware of newer NuGet feed queries. I'd like to say many thanks to NuGet team to make NuGet 1.8 support be able to generate queries that TeamCity's feed is able to understand and process. So, if you like to use NuGet in TeamCity, you need to upgrade to NuGet 1.8.
In v0.8 branch I checked it some code that provides support of the latest NuGet 2.0. There was a bug in NuGet CommandLine installer that filtered NuGet 2.0 out. Starting from NuGet 2.0 it is also required to set an environment variable EnableNuGetPackageRestore to allow NuGet install command work.
I had a set of requests to improve NuGet Packages Trigger performance. The older implementation fetched all packages from the feed to report a trigger state. This turns out to be an overhead both for NuGet trigger and NuGet feed server. Starting from now, NuGet Packages Trigger will only query for latest package (in case you do not specify NuGet version filter). Thanks to Ben Phegan who helped me to find a major bug in the trigger code. Not it is fixed on all active branches: v0.5-bugfix, v0.7 and v0.8
Do you use Prerelease packages? This is nice that it is now possible to mark package as beta or so. NuGet simple treats a package prerelease if the version looks-like 1.2.3-some_word (still 1.2.3 is called not prerelease). Now it is possible to specify if you like to include or to ignore new prerelease packages in the trigger.
I added an Visual Studio Solution file (.sln) parser into TeamCity NuGet Installer runner. Now it no longer requires you to have packages/repository.config file in version control in order to make NuGet Installer work. Installer parses .sln file to collect all project files where to check for Packages.config files. It also fetches packages from Solution-Wide packages file .NuGet/packages.config file.
You may know, there are two ways to update packages under solution from NuGet.exe:
- Call NuGet.exe update solution_file.sln
- call NuGet.exe update Packages.config
I added this option into NuGet Installer runner too. So now you may select the best suitable way to implement packages update.
NuGet Distribution on Agents
Remember, you have to select a version of NuGet from the list of all NuGet versions. It received may feedback messages form uses who tried to use it on the machine behind proxy or firewall. So I added an option in the dialog to upload a NuGet.CommandLine package into TeamCity in case you do not have an access to public NuGet feed or you like to use some custom build of NuGet.
Do you use NuGet integration with TeamCity? Do you have something to share, to ask or to post?
There is a NuGet Packages tab in a build results page. There you may find information on the packages your build used. Now in the tab you may see NuGet packages that were consumed, created or published in/by the build.
Authenticated NuGet Feeds Support
I did much work to make NuGet support Authenticated (aka Http basic authorization) feeds run smoothly under TeamCity. I found some issues in NuGet 2.0 that prevented me to roll out the support now. All my work is available in nuget-auth branch.
Recently I blogged more details about it here
Download and Info:
NuGet support update is available in the latest TeamCity 7.1 EAP, the plugin is also binary-compatible with TeamCity 7.0
For more information, see NuGet plugin
home page at:
or download a latest build from TeamCity here