Last week I did a presentation about the Bowling Game kata in C#.
Last post I talked about installing a local Nuget server and the benefits. However the implementation wasn't as simple and straightforward as I expected, here is the roadblocks I found and what I had to do to make it work. First I installed a local server and then updated the projects to use some of the packages from the local server. The references were updated. Solution builds fine.
Two weeks ago I started migrating all my .NET projects to Nuget, you can read more about it in my previous post. After I was done with my OSS projects, I decided to share the goodness with some of my clients and then came to realize a few issues with my "stop storing dependencies in the repository" crusade. First, many of the dependencies can't be published to the public nuget.org server. That means that we need to find a way to store them locally. Solution: Install local nuget feed.
Why a local Nuget feed is a good ideaHaving a local feed allows your company leverage all the benefits of package management internally. Plus you can use it to cache common used packages in case you have issues downloading them. How to do this you ask? Well, is not as straightforward as I hoped. Luckily I had the help of @davidalpert to fight IIS configuration and @ferventcoder and @davidfawl to answer all our questions. After approximately 3 weeks of tinkering with the server, David managed to make it work. (Kudos, yay!) Here are a few links to follow in order to install the server locally:
- URL should be http://yourserver:port/dataservices/packages.svc
- Add the .nupkg as mime type with application/zip
- Remember that the new server is not an MVC application
- Be patient, very patient...
I got the server running, now what?Well now we have to tackle a different problem. I found that some of the projects are using libraries that are not yet published to the public feed. Though I could package and publish them (I have done so with Structuremap.Automocking and others), some of them are a bit out of date and others are the result of downloading the source, modifying it and compiling it locally. Either case, I thought that I'd like an easy way of packaging and publishing these packages to the local feed in order to keep using them. Doing so is also a great solution if you don't have the time to review if an upgrade would work, or is to risky to do it. If you read my previous post you already know that I'm using Albacore to generate the nuspec file, build the package, etc. My first thought was to use those tasks for each of the packages in need to create. And I started to do so.
Rake again and againAfter creating a rakefile, copying the libs, etc for the third time, my laziness sense (similar to spider sense without the awesome and the great responsibility thing) started to tingle indicating that should be a way of avoiding this repetitive task.
- Copy the assemblies to a lib folder
- Generate the nuspec with the name of the library and the version
- Compile the nuspec and create the package
- Copy the package to the destination to be served by the local feed
- Name of the package
- Version of the package
- Folder where to get all the assemblies
rake deploy:publish[AvalonDock, 1.0, "c:\project\lib\avalondock"]Are you doing anything else cool with nuget? Please share!
It's been a while since Nuget project was released. Since the project birth I've been watching closely to see when would be a good opportunity to start using it for my projects and recommend using it for my clients. Basically, the Nuget project solves dependency management for all your .NET projects. That means that you don't need to search any more for libraries that you need to use like NHibernate or nUnit and just install them from a centralized server.
The path to NugetSo far I've been using Rake for all my builds and I'm super happy with it. Using a DSL specifically designed for building projects is a great advantage, Ruby gives you lots of flexibility and the Albacore gem is the cherry on top. One of the many things that I like about the Ruby world is gem + bundler combination. For .NET projects I've been using also noodle to copy the dependencies to my local folder (usually called lib). However not everything is ponies and rainbows:
- Ruby based solutions are not always well received in .NET project (no matter how good they are)
- Not many developers publish their libraries / frameworks
- Creating gems with .NET assemblies is discouraged since Nuget was born
Nuget AdoptionLast week I say a tweet by @davidebbo saying that Nuget supports now reading from a config file! Why is that so important? Because I don't want to store my dependencies in the repository any more! The assemblies that we use in a project usually don't change until we update a newer version. What's the point of storing them with our code if we can use just a reference to them and download them at our leisure? It takes way less space to store our repositories and updating the packages quite easier because you just change the references and the configuration file, and that's it, everyone gets them. Also imagine sharing in your company all the internal assemblies by publishing them to a local Nuget server instead of having a share drive or similar. Update the version whenever you want! No more versioning dependencies nightmares! And everything is treated the same way, they are all packages! So I installed latest version of Nuget (following the link above) and started the conversion:
Step 1: Changing the ReferencesOpen your .sln file, remove all your references and add them again by doing right click + Add Package Reference. That would accomplish the following:
- Find the reference in the package server
- Install it to a local package folder (usually called Packages)
- Write a config file with the dependency installed (in the same folder as the project)