Personal Code Library + NuGet
As I was getting into my next consulting gig, I found myself copying yet again all of those utility extension methods and classes I tend to pull along with me into every project I work on. Enough is enough, I thought! That and it was a great excuse to finally play with NuGet.
You see, I've been avoiding creating a personal library all this time because I didn't like the idea of having an odd dependency that I included in projects. It would have a foreign or personal sounding namespace, versioning and updating it would be a pain, and developers that came along behind me on the project would have this weird black box of random code. I wouldn't want to run into something like that on a project I joined.
Then I figured out that I could create a NuGet package that was content only. Not sure why I hadn't already put that together, but my original thought was that I would have to create a package that delivered a binary which would be referenced by the target project. Easy versioning and updating taken care of, but I'd still be left with the black box of random code. With a content only package, the actual source code from my "personal code library" actually ends up in and lives in the target project.
The final kicker was my noticing source code transformations. By using the $rootnamespace$ token, the NuGet package installer would transform the namespace declarations into whatever the target project was using. No weird or personal namespaces! Pretty much takes care of every problem I had with creating my library.
I set up a basic class library project and unit testing project. Not that I've done a lot of testing mind you, most of the code in the library has been in my possession for a very long time, but I plan to add tests as I modify and grow the core library.
The interesting part to me was automating the deployment into NuGet. Next to the solution file, you'll see my standard deploy.bat and deploy.proj files (if you've worked with me, you probably recognize these!). In here is where I use MSBuild to grab the current build version, copy all the source to a temp folder, replace my namespace with the $rootnamespace$ token, create the NuGet package, and finally upload the package to nuget.org. Very easy and very cool.
With the addition of a hotkey in Visual Studio (see here for details - I do it similar: no context menu, just a hotkey), updating my personal code in a target project is as simple as updating my library, running deploy, and then updating the package at the target. Crazy easy!
The NuGet Package
The package is called RobTennyson.Common. Installing it is as simple as running this in the Package Manager Console:
PM> Install-Package RobTennyson.Common
I don't know that I'd suggest using it since it's my junk pile and filled with my opinion on how things should be done. It's also likely to change a lot and often. But you're welcome to it if you'd like. You're also welcome to snoop around in it and tell me why I'm nuts for doing this or that (like my .Each and .F extension methods!).
12/21/2011 8:03 AM
I like .F, but .Each is still the devil. This is a very cool, and useful idea, though!
12/21/2011 3:47 PM
LOL - I expected that reaction to .Each! I try to keep its use to a minimum with things like bulk updates and one liners. Anything else generally gets pulled into a traditional foreach loop for readability. When I do want it though, I love having it there. I hope you at least noticed that I don't screw you over due to deferred execution ;) Always good hearing from you Nathan!