SPSherm.MyBlog

There is a more efficient way to do content type IDS than we have done in the past: http://msdn2.microsoft.com/en-us/library/aa543822.aspx

Say we wanted to inherit from "Page", our content type used to look something this (I've split up the lines so it will display properly):
0×010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900
188024C0FF7F45CFB85EBB43980DACF5

Meaning, inherit from "Page" (the red part), include a delimiter (00), and then append a GUID.

If we then wanted to extend this content type, we would do this:
0×010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900
188024C0FF7F45CFB85EBB43980DACF500DFA39D91C06D48BDBC415E7CE80A95CD

And so on… You can imagine how hairy-scary the ContentTypeIDs can get if you wanted your inheritance to go a few levels deep.

As per the article, there is a more efficient way; the second ContentTypeID above could become:
0×010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900
188024C0FF7F45CFB85EBB43980DACF501

Where the tail 01 is the extended content type. Thus, we could have:
0×010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900
188024C0FF7F45CFB85EBB43980DACF501
0×010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900
188024C0FF7F45CFB85EBB43980DACF502
etc.

And then to extend from either of these:
0×010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900
188024C0FF7F45CFB85EBB43980DACF50101
0×010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900
188024C0FF7F45CFB85EBB43980DACF50102
0×010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900
188024C0FF7F45CFB85EBB43980DACF50201
etc.

IMO, this makes the ContentTypeIDs much easier to work with (and read), and we run less risk of running into URL length issues within SharePoint.

PS. The GUIDs used in the above examples have been changed to protect the coder. Any resemblance to any existing ContentTypeIDs are purely coincidental.

Ok, the title is vague, but there's only so much I can put in a title, right?

As per MSDN's documentation for the Microsoft.SharePoint.WebPartPages class and Andrew's post on v3 web parts, we should now inherit from System.Web.UI.WebControls.WebParts.WebPart when we are building custom web parts, except in the four scenarios he mentions (repeating here for my own records):

1. Cross page connections
2. Connections between Web Parts that are outside of a Web Part zone
3. Client-side connections (Web Part Page Services Component)
4. A data caching infrastructure that allows caching to the content database

However, I came across a situation recently whereby a very simple custom web part (all it did was render a "Get Adobe Acrobat" link, essentially) threw a SharePoint error to the screen when used in conjunction with Variations. Here's the steps to replicate:

1. Create your custom web part, inheriting from System.Web.UI.WebControls.WebParts.WebPart. Keep it simple; "Hello World" is fine.
2. Build/deploy, etc. Use it in one of your page layouts. Of course, Variations has to be set up/enabled, but turn off automatic creation of target pages.
3. Once the new page has been created, select either "Update Variations" from the Tools menu.
4. SharePoint will start a long running operation, and then eventually throw an error to the screen.
5. The target variation page is actually created, but this error message is annoying, and probably discomforting to the authors.

It took me a while to figure out what was causing the problem. I finally had a thorough look in the SharePoint logs, and found the message that told me the cause. If you are using SpsDev's ULS Log Reader, filter by Area:CMS, Category:Publishing, or just look for the message "Unable to cast". The relevant part of the message is:

Unable to cast object of type '******.Website.SharePoint.WebParts.AdobeLinkWebPart' to type 'Microsoft.SharePoint.WebPartPages.WebPart'

Um, what? Why does it want to do that? So…

1. Re-write the web part to inherit from Microsoft.SharePoint.WebPartPages.WebPart.
2. Create a new DWP file to match.
3. Deploy, etc; re-test.
4. Of course, it works without the error.

Microsoft's own web parts that inherit from System.Web.UI.WebControls.WebParts.WebPart don't seem to have the same behaviour. Nevertheless, I believe this to be a bug, but one that you should know about when using custom web parts in conjunction with Variations.

The PortalSiteMapProvider class is the base provider used by the four default "CMS" SiteMapProviders:

That is, all of these SiteMapProviders use the same base code to generate a data source, but their "output" differs slightly due to the different attributes that are applied.

Recently, we wanted to filter out the pages from showing up in our left-navigation. You can do this at the rendering stage, but since the PortalSiteMapProvder gives us an IncludePages property, we can simply create a new entry in web.config for our "custom" provider, like this:

<add name="CurrentNavNoPagesSiteMapProvider" description="CMS provider for Current navigation" type="Microsoft.SharePoint.Publishing.Navigation.PortalSiteMapProvider, Microsoft.SharePoint.Publishing, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" NavigationType="Current" EncodeOutput="true" IncludePages="Never" />

By default, there is also a 50 returned-items limit; we can set the DynamicChildLimit to "0" to override this.

<add name="CurrentNavNoLimitSiteMapProvider" description="CMS provider for Current navigation" type="Microsoft.SharePoint.Publishing.Navigation.PortalSiteMapProvider, Microsoft.SharePoint.Publishing, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" NavigationType="Current" EncodeOutput="true" DynamicChildLimit="0" /> 

Of course, you can combine the different properties to come up with a combination you need. The next thing we would need to do is reference these new providers, and voila!

And if you haven't read Chris Richard's series of articles about MOSS Navigation and how to get better performance using the PortalSiteMapProvider, you really should…

Came across this while cruising around:

http://content.techrepublic.com.com/2346-10877_11-895-9.html
http://www.oldcomputers.net/vic20.html

5K (3.5K usable). wow. We also had the tape drive. Wicked. Ask me how we searched for programs on a tape…

And for the record, our *second* computer was an (original, not a clone) Apple IIe with dual disk(ette) drives. My buddy had an Apple IIc, and my future neighbour had an Apple Lisa.

(Ironic how I am posting about one of my old computers, the Apple IIe, which was codenamed "Diana", on this, the 10th year of Diana's death.)

Argh, Sezai beat me to this post about SPFormContext and SPControlMode by a few hours! I have to admit my sentiment is the same as his - I'm super stoked to have found this class.

Oftentimes, we need some code to execute, but only in the "published" state (old MCMS terminology). We might want a component to run certain logic, but it's really only relevant if the page is in a live/published state. In other words, the logic does not matter when we are viewing the page as authors, editors, or administrators – we either don't care, or we just don't want the logic to execute. (Could be vice-versa; execute some code only if we're NOT in published state.)

For example, my UE developer asked me to hide all mark-up surrounding a publishing site field. After all, if there isn't any content to display, then why bother rendering the DIV tags, or possibly some heading (H) tags? By performing a check for content, we can avoid a situation where a "News" header appears, but there's nothing it. So, I created a control that wraps around all the mark-up that comprises a UI element/section. If there is no content, the control, and its children, will not render. However, we always want it to render in editing mode; otherwise, we can't add content back in!

This scenario was fairly simple to solve: write a control that inherits from Microsoft.SharePoint.WebControls.BaseFieldControl, and only run the code to check for content if we are in published mode:

if (this.ControlMode == SPControlMode.Display)
{
    // do something.
}

This is all fine and well, since BaseFieldControl can be traced back to Microsoft.SharePoint.WebControls.FormComponent, which is the last point in the hierarchy that has the ControlMode property. If you go further up the tree, Microsoft.SharePoint.WebControls.SPControl does not have the ControlMode property… I have no idea why not.

Why is this a problem? Well, my UE developer wanted to check multiple fields. I could not inherit from BaseFieldControl any longer, since it is meant to represent a single field, not multiple fields. So I decided to inherit from SPControl instead. (In the end, I probably could have inherited from System.Web.UI.WebControls.WebControl, but it seemed to make sense to stick within the SharePoint namespace.)

After much searching, including spending a lot of time in Reflector, specifically searching for Microsoft.SharePoint.Publishing.WebControls.PageDisplayMode and Microsoft.SharePoint.Publishing.WebControls.SPControlMode (both enums), I finally came across this *internal* and *sealed* class in the Microsoft.Office.Server.Utilities namespace: PageUtility. But we can't use it! However, inside PageUtility is a method called IsPageCurrentlyInSomeEditMode() (nice, huh?) and more importantly, a property called FormContextMode, which returns an SPControlMode object… interesting.

Looking closer, I saw a line (similar to) SPContext.Current.FormContext.FormMode (!!). As Sezai pointed out, FormContext is an SPFormContext object, which contains two (potentially) very useful properties: FormMode and FieldControlCollection:

• FormMode gives us a way to check against the enum SPControlMode to determine what "state" we're in.
• FieldControlCollection returns an ArrayList of field controls (skipping all the other server controls on the page).

Now, I can do a check like this:

if (SPContext.Current.FormContext.FormMode == SPControlMode.Display)
{
    // do something.
}

Also, with FieldControlCollection, I can iterate over the list of defined fields for the current page, looking for some specified fields. Nice!

SPFormContext is definitely useful, and I'm surprised there hasn't been any postings about it until Sezai came along (try searching for SPFormContext…).

When a SharePoint is application is created, a web.config file is created in the application folder you specified. One of the entries inside the SharePoint element is BlobCache. By default, it looks like this:

<BlobCache location="C:lobCache" path=".(gif|jpg|png|css|js)$" maxSize="10" enabled="false" />

In order to improve the performance of your site, the BlobCache should be enabled.

<BlobCache location="C:lobCache" path=".(gif|jpg|png|css|js)$" maxSize="10" enabled="true" />

The maxSize attribute is in GigaBytes, so make sure you have enough room at the location.

Pop quiz: why is it off by default?!

See this article for more information about other caching techniques: http://blogs.msdn.com/ecm/archive/2006/11/08/how-to-make-your-moss-2007-web-site-faster-with-caching.aspx

This isn't in my area of expertise, but a co-worker of mine (thanks Carmen!) alerted me to this, so I figured I should put it here for safe keeping. It's an article that describes the capacity limits for MOSS 2007.

Plan for software boundaries (Office SharePoint Server)

We had a discussion amongst the developers in our group recently: what is an SPSite, what is an SPWeb, and what is the difference? Which once should I work with in my code? Looking at MSDN for the SPSite class, we see this description:

[SPSite] Represents a collection of sites on a virtual server, including a top-level site and all its subsites. Each SPSite object, or site collection, is represented within an SPSiteCollection object that consists of the collection of all site collections on the virtual server.

Mmmmm… ooo-kay… what does that mean?

The SPWeb class simply says:

Represents a SharePoint Web site.

Wow. Enlightening. Looking back to my first experiences working with the SharePoint object model in WSS2/SPS2003, I must say this was one of the more confusing points for me. And it's easy to see why it can be such a confusing/frustrating experience for developers working with the API for the first time. Now that I've worked with WSS3/MOSS code more closely, specifically with Publishing Sites where there are many child "sites", I've come to understand the world of SPSite and SPWeb objects.

The problem lies with the difference in terms used between the SharePoint user-interface and the object model. When we are speaking to end-users, they are familiar with the term "creating SharePoint team sites". However, everytime you create a "site" from the UI, an SPWeb object was created.

It doesn't help that the MSDN documentation uses the following type of naming conventions in their code samples:

SPSite mySiteCollection = new SPSite("http://servername/");
SPWeb mySite = mySiteCollection.AllWebs["Site_Name"];
SPWeb myRootSite = mySiteCollection.RootWeb;

For me, it would have been much clearer if they wrote something like this instead:

SPSite mySite = new SPSite("http://servername/");
SPWeb myWeb = mySite.AllWebs["Site_Name"];
SPWeb myRootWeb = mySite.RootWeb;

While the description for SPSite may be valid, a typical SharePoint application web site only has one top-level site collection. Therefore, in this url http://servername/site1/site1a/, there are actually three SPWeb objects, and only one SPSite object.

SPSite site1 = new SPSite("http://servername/site1/"); 
SPSite site1a = new SPSite("http://servername/site1/site1a/");
bool sitesAreEqual = site1.Equals(site1a);  // sitesAreEqual should evaluate to true.

SPWeb web1 = site1.OpenWeb();
SPWeb web1a = site1a.OpenWeb();
SPWeb rootWeb = site1.RootWeb; // or site1a.RootWeb; would return same instance.

See the SPSite.OpenWeb() method for more examples: http://msdn2.microsoft.com/en-us/library/ms474633.aspx.

SPSite itself is not a "collection" in the sense that comes from CollectionBase, for example. In fact, both SPSite and SPWeb inherit directly from System.Object. Therefore, to use a name such as mySiteCollection is confusing/misleading.

The key thing to keep in mind is that as developers, we need to use the technically accurate terms when speaking with each other (even if MSDN doesn't), and reserve the marketing/UI terms when speaking with people who would never see the object model. (Note: there are examples of these kinds of terminology differences all over the place in SharePoint 2007.)

I hope this clears things up a bit…if you find something that is not correct/accurate, please let me know!

Might as well dive right in and make the inaugural posting useful… 

Anyone who's done some development work with SharePoint probably already knows about this article, but I wanted to place it here for reference:

Best Practices: Using Disposable Windows SharePoint Services Objects

Review the article very carefully… there are things we do often such as getting to an SPSite's RootWeb, like this:

SPSite site = SPControl.GetContextSite(HttpContext.Current);
SPWeb rootWeb = site.RootWeb;

In this case, it's pretty obvious (based on the article) that we need to call rootWeb.Dispose();.

However, if you were to access a property like this:

string rootWebTitle = site.RootWeb.Title;

the article states that you should call site.RootWeb.Dispose(), something that is not obvious, in my opinion. So to keep/ensure your SharePoint site/application runs as smoothly as possible, clean up after yourself! 

EDIT (September 2008):

This is kind of old news by now, but here is another article from Andrew Woodward (which references 3 articles other than MSDN). Worthy to note that we need to properly Close() all PublishingWeb objects as well.

http://www.21apps.com/2008/02/sharepoint-ate-all-my-memory-dealing.html

Roger Lamb's blog has some really good examples. Also make sure to read the comments.

http://blogs.msdn.com/rogerla/archive/2008/02/12/sharepoint-2007-and-wss-3-0-dispose-patterns-by-example.aspx

Stefan Gossner gives a pretty good in-depth look at how memory is consumed.

http://blogs.technet.com/stefan_gossner/archive/2007/11/26/dealing-with-memory-pressure-problems-in-moss-wss.aspx

Finally, a post about application pool/worker process recycling and SharePoint.

http://blogs.msdn.com/steveshe/archive/2007/12/17/overlapped-recycling-and-sharepoint-why-sharepoint-requires-it.aspx