Best practices for creating a shared code library for SharePoint projects

Question

I have several projects for SharePoint 2010 (mostly they are separate solutions built each to separate wsp's) in active development. And I have a similar tasks in these projects (logging, configuration and so on) so there are a same parts of code (or even classes) in different projects.

I though how to implement these parts as shared code library. But the main trouble is that I need to able adding new features to this library, hence it will require to adapt each depended project to this changes, because library assembly is putted in GAC and used by all projects. But it's to hard to support old and finished projects only for using new features from library in other project.

Currently I use a separate library instance per project with different libraries name. But it also causes repeating of code and additional work for moving new feature from one library instance to another.

I was thinking about library versification but didn't a deep exploration of it.

Please give me an advices about best practices for this problem resolving, as this is no especially related to SharePoint, but to any system with modular architecture.

Thanks in advance.

Answer 1

I used the following techniques a few times (with SP2007 and SP2010) :

Library solution

1. Create a SharePoint project "YourLibrary", that contains all the shared code.
2. Package the code in a separate WSP
3. The most important part : create a Farm Feature, empty, auto-activated at the install

The 3rd point is important, because your projects that depends on this shared library, can add a feature dependency to this feature... this allow to ensure the library is installed.

To resume, the library will consists in :

• a Dll, that will be added to the GAC when the solution is installed
• A feature, that will tells the others feature the library is installed.

Managing versions of the library will also be easy, as you can create WSP v1, v2, etc.

ILMerging the output

Another possible technique : use ILMerge in a post build event (testing only with sp2007):

• Set up a classic class library with the shared code
• for each project that depends on this library, add a post build event to merge the main dll with dependent dll.

The main advantage of this technique is that you can keep in one place the shared code. You can also manage several versions of this dll because it's merged into the dll.

The main drawback, is that the result Dll can grow large.

You may also have to be careful with the name resolution... as the system may have several class with the same namespace/class name (one per project that use this technique), you will have to specify explicitly which assembly contains the class you want to use

Linking project files

A third option is to create a project, that contains the shared code. Then, for each project, it's possible to add a code file as a link : in the Add Item dialog, the "Add" button has a small drop down menu, that allows to select either "Add" or "Add as link".

The former case will copy the file into the project, the second will create a link.

This solution is working, but have some dangers :

• you have to deal with multiple assemblies having the same classes (same FQDN)
• you have to be very very very careful when modifying a shared code file. You have to know exactly what are the impact on your code and on other code (other project you are not working on at the current time)

However, this approach can help to share simple utility classes (just have to know what are impacts).