As many of you have probably noticed I’ve been preoccupied the rewrite/repackaging of my Westwind.Globalization library of late and I’m trying to make this library more approachable and easier to get started with. One thing I’ve been struggling with over this beta period is how to best lay out the NuGet packages to make the library as easy as possible to use and get started with while also making it reasonably maintainable.

One of the things to make it easier to get started has been to provide some ‘starter’ content as part of the NuGet package. That is provide a sample page along with a small set set of sample resources that can be imported and let new users both test whether resource loading from the database is working as well as letting her play and see the localized data actually working with the ability to make changes and see the changes reflected in the running application immediately.

You may have noticed the question mark in this post – this means that I’m especially looking for some insights, discussion and ideas how to best approach how to break out the packages  for this library. I have a plan and I’ll talk about it, but it’s not set in stone so if you have any insight or suggestions I would love to hear about it in the comments.

West Wind Globalization current Package Layout

To set the stage here let me describe the current package layout of Westwind.Globalization. Currently there are two NuGet packages:

• Westwind.Globalization
  This is the core package that contains the custom database .NET ResourceManager, the core Database access manager API that deals with serving ResourceSets as well as providing the resource editing and management functionality. There are also libraries for importing and exporting Resx resources and creating strongly types classes etc. In essence it’s all the core, non-Web functionality that can work in any type of .NET project including MVC and Web API projects that don’t use the Web Resource Editor.
• Westwind.Globalization.Web
  This is the ASP.NET Web specific package that contains two separate ASP.NET ResourceProviders, support for the localization administration Web Resource Editor, as well as some WebForms specific features to support meta:resourcekey bindings and a design time resource provider. This package currently also includes the above mentioned sample page and Resx resource files that can be imported into the resource editor.
  

Take 1 – Include the Data in one of the main NuGet Packages

I’m pretty sure the current package layout is not going to last.The ‘core’ package is fine – it contains only an assembly with the core functionality that will work in any project. If you’re using a non-Web project, or an MVC project where no ASP.NET resource Provider is used and you don’t need the Web Resource Editor the Core package alone works. Clean, simple, minimal and no fuss.

The Web package is the problem child. It’s the one that adds all this ‘additional’ content. Specifically if you look at the package layout I have this:

IOW – that’s a lot of ‘extra’ content for a NuGet package.

Pros:

For new projects and getting started it’s obviously very nice to have everything in one package – you install one package and everything you need is there. There’s no searching around trying to find the ‘right’ package, it’s just there.

Cons:

There’s a lot of ‘clutter’ obviously. A lot of stuff gets added to your project – a lot of stuff that you probably will have to remove after you’ve done your initial installation. But even worse with the package layout like this if you delete say all the sample content, and then later do a NuGet Update-Package all that content is restored right back into your project.

Take 2 – A Starter Package

My current thinking is to create a third package – a Westwind.Globalization.Web.Starter package that contains only the sample content. The idea is that you would typically install the starter package into Web projects once, then remove the Westwind.Globalization.Web.Starter package from packages.config and then never see the sample content again during updates or reinstalls. Developers that have used the library before then also don’t have to deal with the extra content as they can just install the raw .Web package.

Note that I would still leave in the LocalizationAdmin interface which is essentially a self contained Web application. I consider it an integral part of the Westwind.Globalization.Web library and I think it belongs into a new project (more on this below). Since the package is geared to be placed into a Web I expect that most if not all people using the library will be using the Web Resource Editor so I think that’s a fair assumption.

Pros:

Allows for cleaner updates (once the starter package is removed). Developers who are experienced don’t have to install the starter package and don’t have to clean up their projects.

Cons:

I have to make sure that I steer new users to the Starter package and explain that they can remove the starter package from packages.config (can’t do this from the NuGet browser as that would uninstall the dependencies as well). Extra maintenance overhead for the extra package as you want to keep the version numbers in sync (even if nothing changes in the content of the package.

Moar???

This is where I’m curious for feedback :-) How do you manage NuGet packages that hold a lot of content? What would you like to see as a consumer of NuGet packages which is probably the most important point.

There’s a fine line between not enough abstraction and too much clutter.

Should this library be broken up into even more packages? Break out the WebResourceEditor as a separate package so all content is sparated out completely from the .Web package? Or does that just create a NuGet package hell?Personally I have to say I’m not a huge fan of libraries with a ton of NuGet references. You know the ones where you do a search for the library in the NuGet browser and you find two pages worth of libraries that pop up with no clear idea which one to load. Ok this isn’t that bad, but you get the idea. It’s nice to have just one thing to install, but there are trade offs obviously. I personally am not a fan of NuGet packages that I install where 5 other packages are pulled in where you often don’t have any idea exactly what they do and what dependencies they have.

For me there’s also the matter of maintaining a bunch of NuGet packages. Making a change to packages up the chain often requires that you rebuild them to ensure the latest versions of packages are loaded for the dependencies (because of NuGet’s inability for options to automatically pick the highest version which sucks).

NuGet really isn’t well suited for content because it does a terrible job of letting you put in content only once and once the content is there does a terrible job updating stuff (some stuff gets updated other stuff is left alone because it has changed – which can be very unpredictable with the only reliable way to update content being deleting the content then updating).

I appreciate any input for discussion…