I came across this in late 2007, and forgot to blog about it. Just catching up, and wanting to post it for reference.

While working with page layouts in MOSS, a few of use sometimes encountered a strange message when we requested the page:

Only Content controls are allowed directly in a content page that contains Content controls.

We'd verify that there wasn't anything in our page layout(s) or master page what was not consistent with ASP.NET syntax. Sure enough, everything in the page layout was sitting (properly) inside an ASP Content server control.

Rather than repeating all the things we looked at to try to resolve the issue, I point you to Rich Finn's article, which ultimately helped me figure out what was going on (see his update at the end of the post).

In a nutshell, ensure your page layout markup uses this casing for all Content web server controls:

<asp:Content … ></asp:Content>

and NOT this:

<asp:content … ></asp:content>

Note the capital "Content" v. the lower case "content" in the second instance. That one issue caused SharePoint to freak out.

I haven't fully confirmed whether or not the last set of asp:Content controls was the issue, or if it was an inconsistency with the opening/closing tags. Nor have I found out what it was that made the controls lower case (could be Visual Studio copy/paste settings), but to be safe, just make sure it's all capitalized and you won't encounter the grief that I did.

There is one other post out there by Waldek Mastykarz which mentions an issue with the PlaceHolderPageTitle placeholder. I haven’t confirmed that the PlaceHolderPageTitle is in fact the root of all evil, but he seems to indicate a similar symptom if you don’t include it in your page layout. In my tests, I did NOT have the PlaceHolderPageTitle, and my page layout still worked correctly after I fixed the case issue for the Content web server control.

Hope this helps you.

Final Note: I encountered this problem in November 2007; I do not remember whether or not I had SP1 installed at the time. If I have a chance to test this again, I will update this post.

(Not in my native Windows environment anyway.) 

I have a few spare moments at work right now. I've got Windows Server 2003 x64 with a local installation of SharePoint as my development environment. (You can debate the merits of this v. using a VM, but I prefer to have direct access to my hardware.) I wanted to check out the VS extensions, so I can quickly do "one-offs" instead of creating full solutions everytime.

I downloaded the extension which can be found here. Tried to install, and boom!

"This product cannot be installed on 64-bit versions of Windows." [OK]

What! No! Not OK. Some digging, and reading the comments on the SharePoint Team Blog, I came across this post: http://blogs.msdn.com/mattbremer/archive/2008/06/17/why-do-visual-studio-extensions-for-wss-3-0-not-support-64-bit-platforms.aspx

Heavy sigh... time to take a closer look at Ted Pattison Group's STSDEV...

I have a custom publishing site definition. It was, of course, based off the default publishing site definition. I re-organized some features around, and added custom versions of required features just so I could control everything a little more to my liking. Anytime we do this, however, we run the risk of "what did I break?" syndrome.

One of my clients was using the Content Editor Web Part on one of her page layouts (instead of using a RichHtmlField - long story). She noted that she could not select the "Use Predefined Table Format" in the Table Editor web dialog. Hmmm... I didn't do anything specific to disable that capability, so I needed to do some digging.

Since I was using a custom publishing site definition, I needed to determine if this behaviour was happening with the default Publishing Portal definition. Sure enough, adding a CEWP to the home page of the Publishing Portal yielded the same effect: I could not use the predefined table formats. I then check the Press Releases default page, which does have a RichHtmlField for me to play with. I can use the predefined formats here. I proceeded to add a CEWP to the zone at the bottom of the page, and here I can also use the predefined formats. Interesting...

I fired up my favourite search engine, and came across this posting from Microsoft: How to enable the "Use Predefined Table Format" setting when you use a Windows SharePoint Services template in SharePoint Server 2007. Cool! But note the location of the CSS: /_LAYOUTS/1033/STYLES/HtmlEditorTableFormats.css. In my case, I have the French language pack installed, which means I have to account for the 1036 LCID also.

I checked the master pages and page layouts that PublishingLayouts feature use, and note that there is not a reference to that CSS. Nor is it in the page layouts found in the PublishingResources feature. What gives? What's the correct syntax?

No matter. I'll just add a link to the CSS by building out the path to the right LCID folder, using something like System.Threading.Thread.CurrentThread.CurrentUICulture to get the LCID. After some frustrations (which I won't get into here), I quickly realized that this would not work in my scenario (Canadian English is not 1033) either.

I looked at the source code for my out-of-the-box publishing portal (the Press Releases page). I noticed that core.css also comes from the LAYOUTS/1033/Styles folder. Some more digging, and I realized that I did not need to speficy the full path, like this example taken from BlueBand.master:

• <SharePoint:CssRegistration name="<% $SPUrl:~sitecollection/Style Library/~language/Core Styles/controls.css %>" runat="server"/>

• <SharePoint:CssRegistration name="HtmlEditorTableFormats.css" />

• <link rel="stylesheet" type="text/css" href="/_layouts/1033/styles/Htmleditortableformats.css?rev=guYGdUBUxQit03E2jhSdvA" />

Here is a great post which talks about what's going on, and what rendres HtmlEditorTableFormats links. It explains why I could not find it in any of the master pages or page layouts: the RichHtmlField web control inserts CSS links to HtmlEditorTableFormats.css and HtmlEditorCustomStyles.css OnLoad() . <groan! />

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):
0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900
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:
0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900
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:
0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900
188024C0FF7F45CFB85EBB43980DACF501

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

And then to extend from either of these:
0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900
188024C0FF7F45CFB85EBB43980DACF50101
0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900
188024C0FF7F45CFB85EBB43980DACF50102
0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900
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:

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

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...

(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:

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:

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:\blobCache" 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:\blobCache" 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