kamagra how much to take

Best Practice For Deploying Shared SharePoint Libraries

I am a huge fan of developing and employing shared libraries across the enterprise regardless of objective, be it third party WebPart interface components or exclusively containing common method implementation. I really enjoy the fact that code base refinement and adjustment can happen so effortlessly with minimal friction when a common baseline of libraries used (very important when using third party components since release cycles are not locally owned). I find myself doing this recurrently during SharePoint development because there are so many gaps within the current API it makes for a lucrative environment to develop cyclic components (i.e. building existence testing for proxy objects that don’t have it OOB) and common code base standards (i.e. when doing something remedial like root SPWeb reference executing corporate exception handling practices in a static method).

One principal issue, and one that I recently had to deal with, is intentional meager checking for globally referenced assemblies within the solution build and malformed solution builds. The SharePoint solution framework does not respect referenced assemblies, nor should it because it is developer accountability (much as it pains me to say).

What I mean by not respecting references is if you have two solutions that use an arbitrary shared library, each specifying the library as a deployment target within the solution manifest, during retraction for the first solution effectively the shared library will be removed, thereby breaking the secondary solution reference to that library resulting in a File Not Found exception. More granularly, each SharePoint solution will have within the solution manifest, in the Assemblies node, DeploymentTarget and location attributes that reference said shared assembly. This is a huge problem, but is working as intended (otherwise the solution framework wouldn’t be very effective would it?) and just requires diligence to correct.

Fundamentally, this is what the problem looks like:

So while the SharePoint solution framework allocates deployment ease and aggregate management; it places an exceptional quantity of power within the user that is responsible for package deployment (who may or may not be a developer). Therefore when using shared libraries that have multiple callers, you have two options. One I like, and the other one I find overcomplicated and a poor approach.

Package and deploy the shared library mutually exclusive from any specific component. Developers are allowed to assume that they can reference that assembly locally during build phases and it will exist in later cycles regardless of where code is moved / deployed.

Within any number of events and receivers, use Reflection, more specifically GetReferencedAssemblies() in order to build an array of all assemblies referenced and inspect whether the retraction should execute. While this seems like a fun option, it doesn’t offer the managerial aspects that the above does.

Share

2 Comments

  1. TJ says:

    Hi Adam,

    “Package and deploy the shared library mutually exclusive from any specific component. Developers are allowed to assume that they can reference that assembly locally during build phases and it will exist in later cycles regardless of where code is moved / deployed.”

    Does the above mean you deploy the Shared Library as a solution. Then in solutions that use the shared library just assume it is deployed and available. Obviously resulting in exceptions if it isn’t?

    Secondly is this the method you use for deploying third party code? E.g. throw there dll’s into a solution and assume they’ll be there for use in any future solution that needs them?

    Lastly if yes to the above. Is a solution per component the best, or 1 shared solution that all 3rd party dll’s regardless of their component/supplier.

    Thanks for your time and thoughts.

  2. Adam Buenz says:

    TJ:

    Correct. I more often than not just deploy my shared libraries as a separate solution, and force the assumption that the references made in development persist to production. There could be some tricky ways to ensure it using a receiver, but I haven’t had the need to enforce it that heavily as of yet.

    Generally, when using third party controls (DevExpress, Infragistics, etc.) this is the approach that I take.

    I usually just dump all the third party crap into one solution, since rev cycles are spread thin and it kills all birds with one stone.

Trackbacks/Pingbacks

  1. FuzzLinks.com » SharePoint Shelter » Blog Archive » Best Practice For Deploying Shared SharePoint Libraries - [...] http://www.sharepointsecurity.com/blog/sharepoint/sharepoint-2007-development/best-practice-for-deploying-shared-sharepoint-libraries/ [...]
  2. Links (7/15/2008) « Steve Pietrek - Everything SharePoint - [...] Best Practice For Deploying Shared SharePoint Libraries [...]
  3. Recent Links Tagged With "bestpractice" - JabberTags - [...] popular public links >> bestpractice Best Practice For Deploying Shared SharePoint Libraries Saved by illihit on Thu …
  4. Recent URLs tagged Sharepoint - Urlrecorder - [...] recorded first by milmusle on 2009-04-20→ Best Practice For Deploying Shared SharePoint Libraries [...]

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>