In my last post I didn’t mention dependencies. Dependencies are their own animal. They require a couple more things to be in place. Let’s talk about those things.
In the .NET world, the dependency for compiled bits is usually an exact version of a reference.
Let me explain. So for example, you have a reference to log4net, and you don’t ILMerge it into your assembly. You now have a dependency that the DLL needs to be there and a particular version (outside of redirecting the bindings). So what I’m getting at is that you require an exact version of a particular DLL. And what you really need is an exact name, version, culture, and public key token of a DLL. But let’s keep things simple. It’s really the version and the name when culture is neutral (and the key shouldn’t change in the same version). So just the name and version.
Adding a Reference as a Dependency
For each reference you have to a library, you find out what version it is (assembly version) and then add that as a dependency. You can do that by cracking open reflector and taking a look at the actual assembly version.
Don’t use the properties. Neither file version or product version are going to be accurate here:
There is nothing out there that says that assembly, file and informational (also known as product) versions have to be the same. .NET relies on the assembly version for referencing. It makes sense that we should as well. Here’s a better example where things are different:
So what would I put in my gemspec? If your reference was to log4net version 18.104.22.168, then you need to assign a dependency to that exact version. Done like so:
I believe you add each referenced dependency to it’s own line.
Now to the sanity check. Before you even add it as a dependency, you want to ensure that the gem exists.
Go to http://rubygems.org and in the top right there is a search box. Search for your reference there.
So let’s search for log4net to be sure it’s there.
Sweet! I can move on to my next reference because the right version of the gem exists.
Keep in mind that the name of the gem may not be the one you are looking for and/or the name may be slightly different. For example. I have a gem for UppercuT. The gem is named uppercutbuild because there was already a gem named uppercut.
Gem Doesn’t Exist?
Now if it’s not there, you can add it. When the actual authors want to start managing the gem, you can just add them as owners so they can push their own gems.
To check the owners of a gem you type:
gem owner gemname
To add someone, according to the gem docs, you issue this command (all on one line):
gem owner gemname --add email@example.com
And that’s it.
You see how I am listed as the owner of the log4net gems? I am not really the developer, when I created the gem, I tied it as closely as I could to the apache project and the committers. When those guys are ready to own the gem, I have the specs for both 1.2.9 and 1.2.10 (both are commonly referred to without the last version octet) and I can just add them as owners.
Before you comment about “cluttering” the ruby community, please be sure to read this (we’re with you on this): http://devlicio.us/blogs/rob_reynolds/archive/2010/07/19/gems-for-net-community-response.aspx
Gems - Package Management for .NET & How To – Gems & .NET
Walkthrough - Create Gems Even Easier With a Conventional Build (UppercuT)!
The Future is Now!
07-17-2010 8:04 AM