2

We have multiple SharePoint projects and features that reference common library code. The library is versioned using the 4 part identifier (x.x.x.x). Each feature may reference a particular version of the library dll.

Our current issue is that when two features reference the same library dll version that dll is removed from the GAC when one of the features is retracted. It appears that SharePoint is ignorant of the multiple usage of the library dll version and, as a result, is blindly removing the dll from the GAC.

This is NOT an issue when each feature references a different version of the library dll.

Are there any workarounds or best practices associated with this issue? We'd prefer to not have to create a unique version or branch of the library code for each feature.

Improve this question

1 Answer 1

Reset to default
3

I typically advise to place "shared" libraries into a dedicated WSP and keep it out project or function specific WSPs. If a specific WSP is retracted, the "shared" library will still be available. Examples of "shared" libraries are: log4net, Enterprise Library, your own shared libraries, ...

Improve this answer
1
  • Our proposed design is essentially the same idea. We will create features for each deployed version of a shared library and use feature dependencies to ensure the libraries are available. For example, we'd have a feature for version 1.0.0.0 of library.dll and a separate feature for 1.0.1.0 of library.dll. The issue we see with this is that there is the potential to have a ton of features; some of which are in disuse. We'll need to keep track of dependencies and remove old features as they fall out of use.
    – etc
    Aug 1, 2013 at 12:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.