Native NuGet Support in TeamCity
August 24th, 2011 by Hadi HaririA few months ago, Scott Hanselman gave a session at TechEd US were he showed some new features we were working on for TeamCity, in order to provide first class support for NuGet. He later blogged about it here.
Instead of delaying until the next release of TeamCity, this feature (like many), has been developed as a plug-in. Eugene, who has been working on it, announced the availability of a first build a few weeks ago. After some initial trials and changes, I decided to setup YouTrackSharp to automate the publishing of the NuGet package. It was surprisingly easy as you’ll see.
1. Installing the Plug-in
If your project is running on TeamCity at Codebetter.com, you can skip to Step 3, since it’s already installed and configured. If not, then grab the latest build from our public TeamCity server. Place the zip file into the plugins folder of your TeamCity installation and restart the server.
2. Configuring the NuGet version
Once the server is running, and agents updated (automated procedure), you then need to tell TeamCity what NuGet version you want to use. The plug-in knows about the nuget.org feed to it can grab the latest version of the command line tool directly. Click on Administration | Server Configuration. If the plug-in installed correctly, you should now have a new Tab called NuGet:
Click on the “Install additional versions of the NuGet.exe Command Line”. TeamCity will read from the feed and display available versions to you in the dialog box. Select the version you want and click Install:
Pull, Pack, Publish
The plug-in offers three main operations:
- Pulling NuGet packages required to build your project
- Creating NuGet packages
- Publishing Packages
In my case, I want to create the package and publish it. To give you a general idea of my build process, here’s the outline of the build steps:
The NuGet related steps are 3 and 4. Step 1 simply builds the project by building the solution file. Step 2 runs the MSpec tests.
3. Building the package
This step is for building the actual package. We create a new Build Step in our project and select NuGet Packages Pack. This will give us the following configuration screen:
As you can see, the configuration is pretty straightforward. Notice that in the Specification file, we can also provide a csproj file as opposed to a NuGet spec file. The advantage to this is that we do not have to redefine information such as version number and copyright information in the spec file. If you’re not familiar with this feature, check out David Ebbo’s post.
I’ve also checked the option to Include Sources and Symbols. This is also explained in David Ebbo’s post and it’s for publishing the sources to Symbolsource. Additional command line parameters (if required) can be passed in the Additional Commandline arguments. If you want to make this a release build, you can also do this by defining Configuration=Release in the Properties field.
Finally I’ve specified the Build number of the package using the TeamCity variable %build.number% which auto increments on each build, and is also used by another feature of TeamCity new in 6.5 which is called the AssemblyPatcher, which I’ll show you as the last step.
4. Publishing the package
The next step is to publish the package. As before, we need to add a Build Step and select NuGet Packages Publish.
This step is even easier to configure. By convention it uses nuget.org as the destination to publish the package. If you have your own NuGet server then fill in the address in the Packages Sources field. If you’re using nuget.org, leave it blank. You need to provide your API key which is stored in a password protected field and finally indicate which packages you want published. Here you can list each package individually or use wildcards. [Note: relative paths are allowed but at the time of writing this post, there was an issue and I was using the full path. This should be fixed soon].
If you want to publish to multiple sources, all you need to do is add another step. Note however that we did not have to specify an extra step to publish the sources to symbolsource.org. TeamCity will follow NuGet’s convention and do this for you automatically.
5. AssemblyInfo Patcher
Although this step is optional I recommend you use it. The AssemblyInfo Patcher is a new Build Feature added to TeamCity which temporarily patches all your projects AssemblyInfo.cs files to update the version number, and then reverts it back after the build is complete. This allows your build number, artifacts, packages and assemblies to all have the same version number. Adding this option is as simple as selecting it from the main project configuration screen:
That’s it. There’s nothing more to it. With a few simple build steps we have now fully automated packaging and publishing NuGet packages. As I mentioned initially, if you’ve got your project on CodeBetter, you already have this feature enabled. If you’re running your own server, just download the plugin and set it up. It’s very simple.
Try it out and please give us your feedback!
August 30th, 2011 at 11:45 am
This would be of great use but unfortunately we can’t get it to work in our TeamCity installation. Our build agent gets is disconnected after we install the plugin and refuses to come back online.
Any ideas on what might cause this?
Thanks in advance,
Emil
October 2nd, 2011 at 3:15 pm
It ublished my API in general public! Stupid tool!
October 2nd, 2011 at 7:46 pm
@Emil,
Can you please contact teamcity-feedback@jetbrains.com?
@Hazzik,
Excuse me?
October 18th, 2011 at 9:29 pm
This is a great idea and perfect for our setup… but I’m hitting a roadblock. I’ve tried a number of configurations for the nuspec file and I still can’t seem to get past the following error:
[pack] Version string portion was too short or too long.
I’ve tried static values pointing to the nuspec file explicitly, and tried the tokens in the nuspec when pointing to the csproj. Same result in all instances.
Any help is appreciated.
October 19th, 2011 at 11:36 am
@Dave,
Can you please email me (hadi at jetbrains dot com) screenshots of your configuration so we can take a look?
Thanks.
October 20th, 2011 at 2:26 pm
Is is possible to configure packaging step to package several projects thus creating several .nupkg files? That is to provide several files in “Specification File” field.
October 20th, 2011 at 4:39 pm
@Artem,
New version already supports that.
October 24th, 2011 at 8:02 pm
Was there any resolution to @Emil’s issue as we are experiencing the same issue.
October 25th, 2011 at 1:09 pm
@Emil, @Christopher
The issue with agent upgrade was recently fixed. Please check you use newer version of plugin.
@Dave,
NuGet does not allow version like “1″. Change build configuration version number to something like “1.0.{0}.2″ and it start to work. You find the pattern at “General” tab of build configuration administration. Another way to do it is to change version number in “NuGet Packages Pack” build runner
November 18th, 2011 at 1:03 pm
How can one publish to a local feed?
I have a network share folder where I can push/publish packages.
I tried to entering the Name of the feed but Visual Studio fails to find the source.
Any advice or pointers please?
November 18th, 2011 at 1:32 pm
TeamCity is calling this on the command line:
C:\TeamCity\BuildAgent\tools\NuGet.CommandLine.1.5.21005.9019.nupkg\tools\NuGet.exe push c:\teamcity\buildagent\work\bfafc0461f80358e\output\MyPackage.1.0.0.0.nupkg %teamcity_nuget_api_key_1234567890123% -CreateOnly -Source “My Local Packages”
but says “The specified source ‘C:\Packages’ is invalid. Please provide a valid source.
How can I set a source that points to a local/network share?
November 20th, 2011 at 12:09 pm
@Eric,
I’ll try and see what the syntax is. Meanwhile you could merely just copy the file locally if you’re reading off of a drive.
November 22nd, 2011 at 11:51 am
Yes, thanks. Still can’t get this to work… but will just have to manually copy the files for now.
November 22nd, 2011 at 12:16 pm
@Eric,
Wanted to check if we had a built-in support for this, which we don’t. NuGet AFAIK does not allow direct publishing to folder either. So you’ll just have to copy.
November 22nd, 2011 at 12:31 pm
oh that’s a shame, will this feature get added in future releases?
December 9th, 2011 at 11:29 am
I’m tring to enable NuGet plugin on the environment without internet access.
Therefore I can’t install NuGet.exe command line via web interface. Could you explain me how can I do it manually?
December 10th, 2011 at 1:54 pm
Maxim, I created an issue for your problem at http://youtrack.jetbrains.net/issue/TW-19365. Please find a workaround there.
December 12th, 2011 at 1:21 am
Almost!
This is very very good.
Working with our in house Lib.sln that contains various *.csproj’s, I got it to package one of the projects by pointing Nuget directly at a *.nuspec that I checked in alongside the *.csproj. The pros is that I have control, and it doesn’t double MsBuild …the con is that it’s very very manual.
I then tried the method you demonstrated — pointing Nuget at the *.csproj instead. But ran into trouble. The issue in our case is that the when Nuget invokes MSBuild, MSBuild can’t resolve the path to the NuGet.Target.
I believe The reason for this is some of the solution’s projects are nested deeper than one down from the *.sln (eg: [checkoutdir]\XAct.Core\XAct.Core\XAct.Core.csproj), and NuGet doesn’t use the Checkout dir, but instead decides the *.sln will be in directory one up from the *.csproj it knows about. As there is no .nuget folder there, it fails.
I tried the following:
Adding \Property:SolutionDir=%env….% to the CommandLine args — but I think those are used by Nuget, not MSBuild (so nothing changes).
Adding \Property:SolutionDir=%env….% to the Properties — but it doesn’t like the ‘:’
I does work if I manually put a *.nuget folder in the [checkoutdir]XAct.Core\ — but that is not a maintainable strategy going forward.
WOuld you have any other suggestion I could try?
By the way — is there a way to invoke it against the Csproj, without it causing a second invoking of MSBuild (double Build) as it’s already been called by the initial build of the Solution?– that would solve two issues in one go, no?
Thank you,
Sky
December 12th, 2011 at 1:34 am
Addendum…
It always like that…as one describes a problem to someone else things go ‘ping’. I just updated Properties to contain:
Configuration=Debug
SolutionDir=%system.teamcity.build.checkoutDir%
And I got a different error:
[11:25:30]: [Step 2/2] pack: Create NuGet package from xact.core\xact.core\xact.core.csproj
[11:25:30]: [pack] An item with the same key has already been added.
[11:25:30]: [pack] Process exited with code 1
[11:25:30]: [Step 2/2] Step CS.FF.XAct.Lib:XAct.Core NuGet Pakage (NuGet Packages Pack) failed
[11:25:30]: Build finished
No idea (yet) what that means (not http://bit.ly/ulrHeY)…but at least the error has changed, and I’m back on the hunt for a solution
December 12th, 2011 at 2:09 pm
@Sky,
Its a bit hard to decipher the issue here on the blog post. Could you please send an email to teamcity-feedback@jetbrains.com and we can try and help you there?
Thanks
December 12th, 2011 at 8:41 pm
Is it safe to assume that this would only work with TeamCity running on a Windows server? We’ve currently put the TeamCity server on a linux machine, with our agents running windows.
December 12th, 2011 at 9:16 pm
@Matt
You still need NuGet to be able to create packages.
December 12th, 2011 at 10:19 pm
@Hadi — To be clear, creating packages happens in TeamCity Server, rather than in TeamCity Agent, right?
December 12th, 2011 at 10:42 pm
@Matt,
Sorry Matt. I didn’t read the part about the agents being .NET. You should be OK then in that sense.
February 1st, 2012 at 2:26 pm
What about the performance, is there any kind of caching? I mean if I refer to several packages and each build will pull it out from nuget.org it will slow down my build process several times.
February 2nd, 2012 at 3:07 pm
tcmaster,
TeamCity does not provide NuGet.org caching. If you like, you may re-publish all referred packages to the local feed. Please feed free to post an issue to the issue tracker for that.
February 7th, 2012 at 3:14 pm
Just wondering…did anybody get this to work?
I have the same problem as sky has.
If you use package restore, which is now in-built into nuget, the msbuild step runs fine.
For whatever reason in the “pack” step, the SolutionDir in the csproj file now “loses” one directory and tries to find the .nuget\Nuget.targets file at a wrong position.
Trying to specify the SolutionDir to Nuget leads to an exception in nuget. For this I have filed an issue on Nuget (http://nuget.codeplex.com/workitem/1907)
FOr those who got this working: How?
February 9th, 2012 at 12:16 am
@Frank
Can you send us some screenshots of your config to teamcity-feedback@jetbrains.com? We can see what the problem is.
Thanks.
February 22nd, 2012 at 6:50 pm
Hi,
I have installed the nuget plugin and restarted the teamcity server. However, I do not see the NuGet version listed in the “server Configuration” tab. I see that the nuget files are unpacked after the restart.
“There are 0 NuGets installed”
Download Nuget
What am i missing in the setup procedure?
Regards
Prasanna
PS: I cannot download from nuget.org directly due to firewall restrictions