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.

Article Or Research Filed Under SharePoint Development.

---

6 Comments »

1. [...] http://www.sharepointsecurity.com/blog/sharepoint/sharepoint-2007-development/best-practice-for-deploying-shared-sharepoint-libraries/ [...]

   Pingback by FuzzLinks.com » SharePoint Shelter » Blog Archive » Best Practice For Deploying Shared SharePoint Libraries — July 14, 2008 @ 5:16 pm

2. [...] Best Practice For Deploying Shared SharePoint Libraries [...]

   Pingback by Links (7/15/2008) « Steve Pietrek - Everything SharePoint — July 15, 2008 @ 5:49 pm

3. 

   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.

   Comment by TJ — January 22, 2009 @ 11:42 am

4. 

   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.

   Comment by Adam Buenz — January 23, 2009 @ 8:49 am

5. [...] popular public links >> bestpractice Best Practice For Deploying Shared SharePoint Libraries Saved by illihit on Thu 05-2-2009 Degrees of engagement with my reading Saved by berberich on Wed 04-2-2009 It’s About Time We Started Listening Saved by kdillin on Tue 03-2-2009 Climate Refugees: resettlement programmes, something for the EU? Saved by blatch on Tue 03-2-2009 Schneider becomes best logistics provider of the year Saved by bmatrix on Thu 29-1-2009 Social Media Best Practices: Listen & Respond! Saved by notbadyo on Wed 28-1-2009 Learning Organizations Get Help from Revised Best Practice Tool … Saved by NOVEY333 on Mon 26-1-2009 List of 100% Free E-books for Online Marketing Saved by ChaninZ on Mon 26-1-2009 When To Code To an Interface Saved by wwwalker on Wed 21-1-2009 La storia delle cose Saved by garyduke on Fri 16-1-2009 COUNCILS SHARE FUNDING TO SPREAD BEST PRACTICE Saved by magneticlabs on Wed 14-1-2009 links for 2008-05-29 Saved by LorraineFroggy on Mon 12-1-2009 Supply Chain Management: Best Practices for Small and Medium Companies Saved by freakydeaky59 on Thu 08-1-2009 mindtangle " Blog Archive " Web2.0 Notes: Designing APIs Saved by hinatahi on Tue 23-12-2008 Spurdog – best practice Saved by misscowbell on Mon 22-12-2008 manIA, 24.08.2008: What NOT to do with your intranet (part 2) Saved by ototochan88 on Fri 19-12-2008 You. Me. Us. Saved by gardian88729 on Tue 09-12-2008 Tool of the Day- Microsoft Group Policy Diagnostic Best Practice … Saved by yanshin21126 on Sun 07-12-2008 Giving Grants to Individuals Saved by indd on Sat 22-11-2008 Another best practice: Command query separation Saved by opentorrent on Mon 10-11-2008 Finding and Keeping Board Members – the role of best practice … Saved by semba on Thu 06-11-2008 Social Media Marketing Best Practice – Everything links Saved by TheSmai on Sun 02-11-2008 Pass4side NetApp(ASAP) Accredited Storage Architect Professional … Saved by kateoneill on Sun 02-11-2008 Ideate – Small Business in South Africa Saved by tiojoca on Thu 30-10-2008 Best Practice Saved by claudine on Wed 29-10-2008 A social media marketing best practice Saved by huring on Thu 23-10-2008 Cicero Introduces Desktop and Best Practice Productivity Packs Saved by SeriousBlackOne on Wed 22-10-2008 Sfondo 96 Saved by kyledeb on Fri 17-10-2008 Old Blog Post: SQL Server 2005 Performance Dashboard Reports Saved by WolfCloud01 on Tue 14-10-2008 SQL Server Best Practices Saved by KanouSomoku on Mon 13-10-2008 Best practices: Please post Saved by RichardLiriano on Tue 07-10-2008 Screw best practice and write for your audience Saved by rsefidgar on Sat 27-9-2008 Redundancy Best Practice Saved by lilscrappy on Fri 26-9-2008 Corporate Governance – Sites Of Interest Saved by ottyke on Sat 20-9-2008 What if we axed press releases altogether? Saved by jchady on Thu 18-9-2008 Office Communications Server 2007 Edge Planning Tool Saved by Slav2Sasuke on Wed 17-9-2008 Always looking for ‘best practices’ stifles innovation -… Saved by GeokoLover22 on Tue 16-9-2008 Best Practice for ID and Class Names Saved by Krumkchick on Thu 11-9-2008 12 rules for blogging politicians – thou shalt not … rules 5 – 8 Saved by SimonST on Sun 07-9-2008 [...]

   Pingback by Recent Links Tagged With "bestpractice" - JabberTags — February 16, 2009 @ 7:43 pm

6. [...] recorded first by milmusle on 2009-04-20→ Best Practice For Deploying Shared SharePoint Libraries [...]

   Pingback by Recent URLs tagged Sharepoint - Urlrecorder — May 20, 2009 @ 11:55 pm

RSS feed for comments on this post. TrackBack URL

Leave a comment

Name (required)

Mail (will not be published) (required)

Website