10

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.

Improve this question

1 Answer 1

Reset to default
5

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).

Improve this answer
5
  • i never ever use auto activate on farm/web app features. I like to have control over what gets activated, for example if i add a new webapp. Commented Sep 17, 2011 at 21:12
  • 1
    the feature is only here to tell that the dll is in the GAC. The feature is actually empty. When the solution is installed, the Dll is push to the GAC, so the DLL is actually available. In this case, I think it's safe to autoactivate the feature. Commented Sep 17, 2011 at 22:06
  • yeah i got that and the reasoning behind it. I still dont think autoactivate is a good idea. webapp scope is worse than farm scope tho :-) Commented Sep 18, 2011 at 13:46
  • I used to use the ILMerge technique in SP2007 - it worked great! However, it doesn't work at all with the Visual Studio 2010 templates for SharePoint 2010. Commented Sep 20, 2011 at 17:37
  • I see two workaround possibles (not tested): 1. you can "patch" the wsp from a post build event or a small script : 1. uncab the wsp 2.ilmerge the assemblies 3. update the manifest 3. recab the wsp. 2. find a msbuilder guy to add the ILMerge in the compilation target (I'm not such guy... that's only an idea) Commented Sep 20, 2011 at 18:53

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.