Monthly Archives: March 2009

Sharepoint Object Model

Maybe this is just me again – but I find the relationship between terms used in the SharePoint UI and the SharePoint Object Model (OM) slightly confusing – especially the relationship between the UI Site Collection and Site and the OM SPSite and SPWeb.

SharePoint UI terminology:

a. A Web Application relates to the IIS directory typically created in the ‘inetpub’ directory .

b. The Web Application definition includes the specification/creation of an initial ‘Content Database’ used to store content – though additional Content Databases can be created at a later date.

c. After creating a Web Application you are prompted to create a Site Collection (the collection is stored in the Content Database). The Site Collection is seen as the ‘bridge’ between the logical structures (your content) and the physical implementation (the content database).

d. The Site Collection is identified by the associated URL (which links into the use of managed paths).

e. The creation of a Site Collection includes referencing a SharePoint template – which in turn creates additional libraries and activates features associated with the template.

f. Based on the template you can then create additional Sites within your top-level Site using the SharePoint UI (better thought of as sub-Web sites).

SharePoint Object Model terminology:

a. The Web Application is represented as a ‘SPWebApplication’ object.

b. The Site Collection is actually a ‘SPSite’ object (accessed using the URL in the constructor when creating an instance).

c. To access all Site Collections within a Web Application use the ‘Sites’ property of the ‘SPWebApplication’ (returns a ‘SPSiteCollection’ collection of ‘SPSite’ objects).

d. To access the top-level Web site within a Site Collection use the ‘RootWeb’ property of the ‘SPSite’ object (returns an ‘SPWeb’ object).

e. To access the sub-Web sites of a Web Site use the ‘Webs’ property of the ‘SPWeb’ instance (returns the first level of child web sites).

f. To access all sub-Web sites in a Site Collection use the ‘AllWebs’ property of the SPSite object.

In summary…

SharePoint UI/stsadm Object Model

Web Application SPWebApplication

Site Collection SPSite

Site (aka Web site) SPWeb

The confusion goes on it that if you refer to the SharePoint Content Database management UI this refers to the number of Sites you can have in a Content Database (warnings and maximum) – the UI Site reference in this context refers to a Site Collection.

To Strong Name or Not to Strong Name

Awhile back, I did some research on strong naming (ie signing) and the GAC. I thought it might be an interesting post. We ultimately signed all of our assemblies.

When strong names MUST be used:

  1. Any assemblies loaded into the GAC must have strong names.
  2. For a .NET class to take advantage of Enterprise Services (COM+ Services), such as distributed transactions and object pooling, the assembly that contains the class—called a Serviced Component because it inherits from the class EnterpriseServices.ServicedComponent—must have a strong name.
  3. For a .NET component to be used by a non-.NET component. (This is the reason we ultimately signed all of our assemblies, since we have a component that must be called by a VB 6.0 app).

Advantages of using strong names:

  1. Versioning: Eliminates DLL Hell

    – Developers can uniquely identify versions of .NET assemblies.

    – Different versions of the same assembly can run side-by-side.

  2. Authentication

    – Strong names ensure the code is provided by the publisher.

    – Strong names can be used with code groups to provide levels of access to the assembly. For instance, Admins and Developers can use strong names with code groups to provide assemblies with higher permissions than the default .NET framework permission level.

  3. Binary Integrity

    – The CLR can tell from the signing of the assembly whether it has been tampered with since it was last compiled.

  4. Potentially fixes a problem where shared assemblies get added multiple times in a Microsoft Setup Project. This may not be necessary with Beta 2, though.

Disadvantages to using strong names:

  1. Creates additional work to go through and sign every assembly in a project (and every assembly referenced, like Enterprise Library Assemblies).
  2. When you sign assemblies, the CLR first looks for the assembly reference in the GAC and if it cannot find it, it then probes for it. This could be inefficient for your processes if you have no assemblies in the GAC.
  3. Signing the assemblies will bring tighter security, and may cause a security issues between assemblies, requiring more troubleshooting time to figure out the problems.

Note: If you decide to sign your assemblies and you are using Enterprise Library, you will have to ensure that every assembly you use is referencing the signed copy of Enterprise Library. This gave us fits.