I’ve been working on writing .NET bindings for Rollbar, an error and message reporting service, like Airbrake. My library is working nicely and is published in the NuGet gallery.
So now I want to take it to the next level of usability and implement an NLog Extension for this. This entails writing one screen’s-worth of code and referencing the NLog library. It’s a wrapper. I may also implement one for Log4Net.
At this point it’s already getting blurry as to how I should organize this and manage it with source control and nuget. One thing for sure is that there will be separate nuget packages so people don’t have to install dependencies they don’t want.
My questions are:
-
Should I create separate git repositories for the base library and NLog extension and Log4Net extension? Seems like it would be easier to track changes have clearly separated build processes and such. It may make contributing to the project(s) easier…but I’m not sure.
-
Should I reference my Rollbar base library as a dependency of the extension libraries, or ILMerge it? The upside to ILMerge is the user only needs one reference and DLL. The odd part is with versioning. Like how to have version numbers that make sense when only the base library changed, or only the extension changed. Also, it seems like nuget doesn’t list updates to dependencies of installed packages, only to the packages itself. I’d want updates to the base library to bubble-up as an update the user should install! I suppose one way to do that would be version-bumping the extension and setting the version of the dependency library.
This is my first foray into writing an open source library and publishing it and managing it. I’d love some feedback from people who have dealt with this so I can get it right!
I’m using Albacore for my build process, for what it’s worth.
(Current code: https://github.com/mroach/RollbarSharp)
I wouldn’t mind including a useless-to-me, small DLL as part of a bigger package, but I wouldn’t want to include that and NLog, so that I can use Rollbar with log4net.
So, if you are going to include them in the main package, don’t make the package dependent on the secondary product. Because it’s not dependent. I don’t need NLog to use Rollbar. But, note that this means I’ll be able to install any version of NLog alongside Rollbar, which means I’m screwed if I pick one that’s incompatible.
There are plenty of open-source projects on nuget that link two others and have combined names, like Rollbar.NLog, which makes them turn up next to Rollbar when I’m searching but gives me the choice whether to include them or not.
If you take that option, you can make version numbers independant, by setting dependency versions. For example, you say Rollbar.NLog v1.2 requires Rollbar v1.x (the dependency tag in your nuspec file, (id="Rollbar" version="[1.1,1.2)") and give me permission to upgrade the two packages independently, as long as neither is upgraded to v2.x.
If you have a Rollbar.NLog package then you should make it dependent on NLog. If you can be confident of NLog’s versioning (eg. will always be backward compatible, unless the major version changes) then give me freedom with that too. But you don’t have to. You can specify id="NLog" version="[3.2.1]". Doing so makes it safe for me, but less flexible — my NLog upgrade strategy is tied to your release strategy.
2