Two lines:

$w = Get-SPWeb "http://sps2010"
$w.Lists.Delete([System.Guid]$w.Lists["My Custom List"].ID)

One line:

Get-SPWeb "http://sps2010" | Where-Object { $_.Lists.Delete([System.Guid]$_.Lists["My Custom List"].ID) }

or

Get-SPWeb "http://sps2010" | % { $_.Lists.Delete([System.Guid]$_.Lists["My Custom List"].ID) }

• http://blogs.msdn.com/brianwilson/archive/2007/03/05/part-1-event-handlers-everything-you-need-to-know-about-microsoft-office-sharepoint-portal-server-moss-event-handlers.aspx
• http://www.davehunter.co.uk/Blog/Lists/Posts/Post.aspx?ID=69

That command is:

C:\windows\system32\IISApp.vbs /a "SP Site App Pool" /r

(Note that the first time you run IISAPP.vbs, you’ll get a few confirmation prompts.)

This VBS script does not exist in IIS7 on Windows Server 2008, but the good news is there is an even better command:

c:\windows\system32\inetsrv\AppCmd Recycle AppPool "SP Site App Pool"

Type “AppCmd /?” for a list of all the useful actions you might want perform against your IIS7 installation.

It’s about time I wrote about the experiences of what was the SharePoint Conference, 2009 edition, in Las Vegas. By now many others have had their recap, and with my own experiences being somewhat similar, I shall try to keep mine succint, but entertaining.

My first major Microsoft conference was the Office/SharePoint conference in Redmond (or was it Bellevue) in March 2005. I had just started with Habañero Consulting Group, had just gone through a nasty learning experience on a custom “workflow” type issues and tasks solutions on SharePoint 2003 (which was NOT fun for many reasons), and so was pretty wide-eyed and overwhelmed when I attended the sessions. Aside from the two co-workers I went with, I knew no one else, didn’t know any of the “big names”, and didn’t really have any sort of game-plan whatsoever. We heard a lot of ideas, I saw some code, saw some bad presentations, and concluded the conference with pretty much a “meh”. The most exciting part was the road trip from Vancouver in my car, and I’ll never forget the “thud” that my car had to endure as I drove it off a curb because my “navigator” (she will remain nameless, for now…) missed the exit, it was dark, and I was desperate to turn around and find the hotel.

SharePoint Conference 2008 came to Seattle in February, if i recall correctly. Due to the success the product had in 2007, it was going to be a big deal for SharePoint 2007, with which I’d been working since the summer of 2006 (Beta 2). Having spent two years prior on MCMS 2002, I was fortunate to be involved in a WCM solution in the summer of 2007. By then, I had learned a lot through discovery, but also through reading the content of others. I also attended the first running of Andrew Connell‘s WCM401 online class. I had a bit of a game plan this time, but it mostly involved the sessions, attending them as strategically as I could, trying to learn things outside of my SharePoint comfort zone. I learned some new things, saw better presentations, but generally didn’t feel as out of place as I did in 2005. I attended SharePint, met a few people throughout the conference, but pretty much stayed with my co-workers and didn’t realize the social aspect of these conferences. Since the two MOSS exams were available for free, I decided to give them a shot and passed both. Cool. The stay at the W was also a nice luxury that Habanero generously provided.

Throughout 2007 and 2008, I was focussed primarily on SharePoint projects. I learned more and more with each one (as one should), became more confident, and looked forward to the next conference. Soon after it was announced, I bought an early-bird ticket. Throughout 2009, I grasped on to Twitter, started following a few SharePoint people, and once in a while would engage in some sort of “conversation” with people whom I’ve never met. It was very cool. Heading down to Las Vegas for SPC09 I decided I would try to meet as many people as I could, to personally thank them for the work they have put into the community over the last few years from whom I’ve benefitted directly as well. I decided to splurge a bit and stayed at THEhotel, attended SharePint at EyeCandy, and throughout the conference just shook hands and tried to track down a few people to say “hi” and “thanks”. I had never been to Vegas before, but it wasn’t until Tuesday evening (after the 80s party with Huey Lewis and the News) that I even stepped outside of the Mandalay Bay Center.

It was a great conference with a lot of content (overload), but what made it really special for me was the chance to meet many of the cool people in the SharePoint community of which I’m proud to be part of.

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 specify the full path, like this example taken from BlueBand.master:

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

but instead I needed simply this:

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

and SharePoint takes care of the rest, building out the path to the appropriate Styles as required, like this:  

<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 renders 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! />

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 could 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
0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900
188024C0FF7F45CFB85EBB43980DACF503

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.

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.

• GlobalNavSiteMapProvider
• CombinedNavSiteMapProvider
• CurrentNavSiteMapProvider
• CurrentNavSiteMapProviderNoEncode

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…

<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

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