SPExLib Manifest

This outlines the basic structure of the SharePoint Extension Lib project.

This is subject to change at anytime...

To make SPExLib more easy to use It will have two different assemblies, one targeting the WSS 3 platform and the other one MOSS 2007. And it will have set of namespaces each targeting different parts of the extensions and utilities.

Make sure that you document everything inline, documentation will be created as a CHM file

SPExLib.dll

The basic SPExLib assembly, will have the following namespaces

SPExLib.SharePoint

Extensions to the SharePoint object model

SPExLib.SharePoint.Linq

Linq extensions for the SharePoint API's

SPExLib.System

Extensions to the .NET Fx object model

SPExLib.Controls

Controls and helper classes for controls, fields and WebParts

SPExLib.Utilities

Other utility classes, such as logging etc

SPExLib.Server.dll

This assembly contains the extensions for the MOSS 2007 platform

SPExLib.SharePoint.Server

Extensions to the MOSS 2007 object model

SPExLib.SharePoint.Server.Linq

Linq extensions to the MOSS 2007 object model

Last edited May 24, 2009 at 5:22 PM by wictor, version 4

Comments

wictor May 24, 2009 at 10:31 PM 
Great, solution is updated, so code away!

dahlbyk May 24, 2009 at 9:14 PM 
Fair enough. Gary's work has a different goal and deliverable, just thought I'd throw it out there. :)

wictor May 24, 2009 at 5:14 PM 
Good, a Linq namespace might also be good, to avoid cluttering of all namespaces and good separation.
I can't agree on using conditional compilation instead of using two assemblies. I can see it problematic sometimes to know which one is used or installed. Instead having two separate assemblies will allow you to have more flexibility and avoid accidentially using a DLL with a larger footprint.
/WW

dahlbyk May 24, 2009 at 2:43 PM 
I think this structure makes sense. I would also suggest a SPExLib.SharePoint.Linq namespace for all the IEnumerable<T>-style extensions, as there will potentially be a lot of them and they really clutter up intellisense.

Rather than provide a second MOSS-specific DLL, we could also use Gary Lapointe's technique to provide different versions of the same assembly:
http://stsadm.blogspot.com/2008/06/wss-build-of-my-stsadm-extensions.html
Not sure if this would be easier than a second project/assembly.