Rich Finn

So, earlier I posted how I upgraded WSSv3 to MOSS.

After I completed that task, I wanted to see what it would take to turn my existing top level site collection into a publishing site, as the Publishing Feature is one of the lowest hanging fruit in the MOSS Feature stack that has the greatest benefit to both users and administrators right out of the gates.

The first thing we need to do is enable the Office SharePoint Server Publishing Infrastructure feature in the site collection features list.

Uh oh:

The logs say that access was denied activating the Publishing Resources feature and the message is 'Provisioning did not succeed. Details: Failed to provision the scheduling job definitions.  Page scheduling will not succeed.'  Then there are some other messages in the logs that say that an exception was thrown ensuring dependencies were met for the Publishing Site Feature.

According to a post I found on NetAdminTools.com, you can activate the Publishing Resources via stsadm, then click the Activate button in the site collection Features list.  This seemed to work pretty well:

Then I activated the Office SharePoint Server Publishing Feature in the Site Features list (in the Site Administration group) and the Pages list was created and the site actions menu was expanded, and there was much rejoicing (yaaay)

BUT WAIT!

When I created a new page, something seemed off.  There were only a few pages available in the 'choose page layout' list box.  Looks like some article pages and welcome pages were missing.  I went to the mast page gallery and saw that there weren't any pages missing, but there were some pages, like the welcome page with web part zones page layout - which is the page layout used on the default page of the Collaboration Portal site definition - that were not associated to their proper Content Types! Uh - Weird!  How did this happen, and how can we fix it?

Creating new site collections based on the Team Site template proved that we could activate the Publishing Infrastructure Feature without the access denied error, but the page layouts still didn't have the Content Type associated in the Master Page Gallery. Tried this on four site collections.  PublishingPrerequisites, PublishingResources, Navigation, and PublishingLayouts are the Feature Activation Dependencies on the PublishingSite Feature (the Publishing Infrastructure Feature name) and they are all scoped to the site, so why are the page layouts not getting associated with the Content Types?

Creating a new site collection based on the Collaboration Portal site definition worked fine, and the page layouts were associated correctly. Lame.  Must be the order that the site Features are activated.

After going through the Features listed in the onet.xml file for the Collaboration Portal site definition in the order defined, order's NOT the problem.  What is you ask?

So - turns out that the page layouts are tagged as being part of the Master Page Content Type - what's up with that?!?
 

Eidt the page and change the Content Type to the correct one (Page Layout), then set the Associated Content Type.

Check In, Publish a Major Version, and Approve it. Fixed!

Bug...

This seems to have come up a lot for me lately: We have a client who wants to know what it takes to upgrade from WSSv3 to MOSS. What do they need to do to make the MOSS Features available in their current WSS sites?

Having been primarily only working with MOSS, I haven't done much with just WSS and have never run through the upgrade process to MOSS.  There was very little documentation out there other than some forum posts, so today I ran through it for the heck of it and was impressed, but unsurprised, that it was pretty smooth.

To begin, I installed the slipstreamed WSS+SP1 available from Microsoft downloads onto a fresh Windows Server 2003 virtual.  I set it up using SQL 2005 instead of SQL Express, which was a little lazy on my part, because I should have run through what it would take to move the SQL Express stuff over to SQL 2005. Oh well.

I set up my web application with a site collection at the root based on the standard Team Site definition.  This site then got two sub sites.  All three sites had a single Word document in it's Shared Documents doc library.

Then, I installed MOSS+SP1 from MSDN Subscriber Downloads. Here's the steps with some screen shots that I thought were of value:

1) Ran install of MOSS.  Pretty straightforward.  Extracted files, entered key, selected server type, installation of bits and securing of resources, etc, etc...

2) Ran configuration wizard. Says 'This wizard will upgrade SharePoint Products and Technologies'. Config wizard is aware of config db. Runs through nine tasks without hanging on anything for too long, and then completes.

3) Opened Central Admin. On the Operations tab:

When clicked:

Check and click OK:

Completed pretty quick:


One thing to note here - this just enabled the Enterprise SKU Features, I think because I entered an Enterprise key from MSDN, so none of the Standard Features were activated. FYI...

4) Started new services:

5) Created SSP - nothing special here

6) To get Search lined up, I created a Search Center site at the root of the site collection, and changed the site collection search settings to use the new search center I just created:

That was pretty much it. Like I said, impressed, but not surprised.

In our current SharePoint project, we have a custom site definition based on the out-of-box Publishing Site with Workflow. We found a little problem with this though, because when the out-of-box Features for Publishing and it's Parallel Approval workflow are activated, the default SharePoint Approvers group is the only group that is set to approve a publishing page that has been sent into the workflow. The problem is, we want to inherit the parent site's workflow settings - otherwise known as the association data - because our application has 'channels' of content that each has a different group who can approve the content in their appropriate channel.

The group that can approve publishing pages in each channel is defined in the root web of the channel by doing nothing more than editing the Parallel Approval workflow on the Pages list, and then setting the correct group on the People Picker for the workflow approvers property. Since channel owners can create new sites in their channel using our custom provisioning process, we don't want them to have to go into the Pages list workflow settings to set the correct group every time, because as we all know, people make mistakes. Why not automate this process and set the right approvers group for the channel owner when the new site is created?

To do this, we created a Feature that we included in our custom site definition.  When a new site is created and the Feature is activated, we execute the following code:

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.SharePoint;
using System.Diagnostics;
using Microsoft.SharePoint.Workflow;
using System.Xml;
using Microsoft.SharePoint.Publishing;

namespace Demo
{
    public class FeatureReceiver : SPFeatureReceiver
    {
        public override void FeatureActivated(SPFeatureReceiverProperties properties)
        {
            //get the SPWeb object for the Feature's scope
            SPWeb currentWeb = properties.Feature.Parent as SPWeb;

            //set the AllowUnsafeUpdates property to true so we can apply the change to the workflow
            currentWeb.AllowUnsafeUpdates = true;      

            //get the parent web of the current web - this is where the correct workflow settings are
            SPWeb parentWeb = currentWeb.ParentWeb;
            
            //get the Pages list from the current web using the PublishingWeb object
            SPList currentWebPublishingList = PublishingWeb.GetPublishingWeb(currentWeb).PagesList;

            //get the current web Pages list's workflows
            SPWorkflowAssociationCollection currentWebWorkflows = currentWebPublishingList.WorkflowAssociations;

            //if the site has workflows, we need to get the parent web's workflow and apply the same approvers to it
            if (currentWebWorkflows.Count >= 1)
            {
                //find the parallel approval workflow
                SPWorkflowAssociation currentWorkflowAssociation = currentWebWorkflows.GetAssociationByName("Parallel Approval", currentWeb.Locale);

                //empty container for the parent pages list workflow
                SPWorkflowAssociation parentWorkflowAssociation = null;

                //get the parent site's pages list
                SPList parentPagesList = PublishingWeb.GetPublishingWeb(parentWeb).PagesList;

                //if there's workflows attached, we need to find the Parallel Approval workflow
                if (parentPagesList.WorkflowAssociations.Count > 0)
                {
                    parentWorkflowAssociation = parentPagesList.WorkflowAssociations.GetAssociationByName("Parallel Approval", parentWeb.Locale);
                }

                //if we have the parent workflow, we need to copy the review settings to the child
                if (parentWorkflowAssociation != null)
                {
                    //xmldoc for the parent association data
                    XmlDocument parentAssociationData = new XmlDocument();
                    parentAssociationData.LoadXml(parentWorkflowAssociation.AssociationData);

                    //xmldoc for the child workflow association data
                    XmlDocument currentAssociationData = new XmlDocument();
                    currentAssociationData.LoadXml(currentWorkflowAssociation.AssociationData);

                    //we need to create a namespace manager object because the xml data we want is 
                    //namespaced with 'xmlns:my="http://schemas.microsoft.com/office/infopath/2003/myXSD"'
                    //the following code was obtained from John Wood's blog
                    //url: http://www.dotnetjunkies.com/WebLog/johnwood/archive/2005/08/25/132153.aspx
                    //this code will add all namespaces in the xml to the namespace manager, allowing us to correctly
                    //create XPath queries to retrive the data we need

                    XmlNamespaceManager nsmgr = new XmlNamespaceManager(parentAssociationData.NameTable);
                    foreach (XmlAttribute attr in parentAssociationData.SelectSingleNode("/*").Attributes)
                    {
                        if (attr.Prefix == "xmlns")
                            nsmgr.AddNamespace(attr.LocalName, attr.Value);
                    }

                    //get the Reviewers node from the parent workflow
                    XmlNode parentReviewers = parentAssociationData.SelectSingleNode("//my:Reviewers", nsmgr);

                    //get the Reviewers node from the child workflow
                    XmlNode currentReviewers = currentAssociationData.SelectSingleNode("//my:Reviewers", nsmgr);

                    //set the Reviewer node of the child workflow to be the same as the parent
                    currentReviewers.InnerXml = parentReviewers.InnerXml;

                    //update the child workflow's association data
                    currentWorkflowAssociation.AssociationData = currentAssociationData.OuterXml;

                    //update the child workflow association in the database
                    currentWebPublishingList.UpdateWorkflowAssociation(currentWorkflowAssociation);
                }
            }

            //make sure you dispose of the parentWeb object
            parentWeb.Dispose();
            
        }

        public override void FeatureDeactivating(SPFeatureReceiverProperties properties)
        {
        }

        public override void FeatureInstalled(SPFeatureReceiverProperties properties)
        {
        }

        public override void FeatureUninstalling(SPFeatureReceiverProperties properties)
        {
        }
    }
}

I just updated the Ajaxify MOSS codeplex release to include the needed web.config entries for using the .Net 3.5 version of System.Web.Extensions.

There is, however, one manual step you still have to perform to the web.config files in order to get this to work right. You still need to add the dependentAssembly elements to the configuration/runtime/assemblyBinding element, as shown below:
 

I tried a whole bunch of different ways to get the xpath in the SPWebConfigModification object to try and get it to work, but I think the problem is that it's either too ambiguous because there's no unique identifier available on the dependentAssembly element, or the namespace on the assemblyBinding element is causing problems.

All the other entries are being applied correctly, though.  Also, I try and help out a little by outputting the nodes in the stsadm command output after the nodes are applied :) - see:

Just mark and copy the lines from there, and you're halfway there.

The command names are on the releases tab in the codeplex project.  If you're upgrading from the ASP.Net AJAX 1.0 framework, make sure you uninstall the config mods first, before you add the 3.5 config mods.

Final note: I hope to be adding the needed lines for SilverLight pretty soon.

A few days ago, I mentioned that we're trying to automate as much as possible in our new SharePoint based product, and I explained how we are creating custom search scopes in a Feature Receiver.

Another component we're automating is the creation of Crawl Rules for the search engine in the SSP the site collection is associated.

According to MSDN crawl rules are defined as follows:

Crawl rules provide you with the ability to set the behavior of the Enterprise Search index engine when you want to crawl content from a particular path. By using these rules, you can:

• Prevent content within a particular path from being crawled. 

• Indicate that a particular path that would otherwise be excluded from the crawl should be crawled.

Here's how we're creating the crawl rules in code using a similar Feature Receiver as before:

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.SharePoint;
using Microsoft.Office.Server.Search.Administration;
using System.Diagnostics;

public class FeatureReceiver : SPFeatureReceiver
{
    SPSite currentSite = null;
    public override void FeatureActivated(SPFeatureReceiverProperties properties)
    {
        //Debugger.Launch();
        this.currentSite = properties.Feature.Parent as SPSite;
        createCrawlRules();
    }

    private void createCrawlRules()
    {
        //get the site SSP's search server instance
        SearchContext searchContext = SearchContext.GetContext(this.currentSite);

        //For this example, I'll just show how to exclude the Explorer view of a list
        //Notice how we're using wildcard characters to specify that every /Forms/WebFldr.aspx page
        //    will be excluded regaurdless of protocol or location in the site collection
        string crawlRule = " *://*/Forms/WebFldr.aspx";

        //get the content source for the search server
        Content sspContent = new Content(searchContext);

        //check to see if the crawl rule exists, and create it if it doesn't
        if (!sspContent.CrawlRules.Exists(rule))
        {
            

            //create the crawl rule, setting the type of crawl rule and the crawl rule string
            CrawlRule crawlRule = sspContent.CrawlRules.Create(CrawlRuleType.ExclusionRule, rule);

            //we want to make sure that the rule still works if there are querystring variables
            crawlRule.FollowComplexUrls = true;

            //at this point, you can set other properties such as authentication information to crawl
            //    content using a different identity or authentication method
            //    for more info , check out http://technet.microsoft.com/en-us/library/cc263150(TechNet.10).aspx

            //commit the rule in the database
            crawlRule.Update();
        }
    } 
public override void FeatureDeactivating(SPFeatureReceiverProperties properties){} 
public override void FeatureInstalled(SPFeatureReceiverProperties properties){} 
public override void FeatureUninstalling(SPFeatureReceiverProperties properties){}       
}

I've recently been working on a SharePoint project which is being offered to clients as a product built on top of the SharePoint framework.  While I can't describe in too much detail exactly what the product is, I figured it might be beneficial to discuss how we've built out certain aspects of the solution.  At the very least, I can compile some notes of my own so I can remember later how tackled some of the issues we had during the dev process.

To give a little background on the product, at the core, this is primarily a publishing-based solution that is deployed into a site collection. One of the goals in the development of the product has been to automate the creation of the site collection as much as possible when a new client purchases the product.  We're handling the bulk of the new client deployment through a Feature called 'Product.SiteConfiguration' that when activated, executes a Feature Receiver that both creates some higher-level components and populates 'default' data in areas of the site that are required for the product to function properly.

One of the things we're creating in the SiteConfiguration Feature Receiver is a locally defined, custom search scope that is specific to the site collection of the product. A search scope allows the narrowing of search results based on rules defined within the scope, so we wanted to create a scope that is specific to the product so that when a user searches from the product's generic search box, only items from within the product are returned.

Here's sample code used to create a new scope in a site collection:

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.SharePoint;
using Microsoft.Office.Server.Search.Administration;
using System.Diagnostics;

namespace LocalDev.Demo.Code
{
    public class SiteConfiguration : SPFeatureReceiver
    {
        SPSite currentSite = null;

        public override void FeatureActivated(SPFeatureReceiverProperties properties)
        {
            string scopeName = "ProductScope";

            this.currentSite = properties.Feature.Parent as SPSite;
            
            //get the site SSP's search server instance
            SearchContext searchContext = SearchContext.GetContext(this.currentSite);

            //get the current scopes defined in the search server
            Scopes scopes = new Scopes(searchContext);

            //create a URI object for the current site - used in checking for the scope we're creating
            string siteUrl = this.currentSite.Url;
            Uri siteUri = new Uri(siteUrl);
            
            //create scope object for the new scope
            Scope newScope = null;

            try
            {
                //this is a little bit of a hack, but if it bombs, we know the scope doesn't exist
                newScope = scopes.GetScope(siteUri, scopeName);
            }
            catch
            {
                //create the new scope
                newScope = scopes.AllScopes.Create(scopeName, scopeName + " Description", siteUri, true, "/_layouts/product/customsearchresults.aspx", ScopeCompilationType.AlwaysCompile);

                //create the scopes rules for the new scope
                //for example, include content from the site
                newScope.Rules.CreateUrlRule(ScopeRuleFilterBehavior.Include, UrlScopeRuleType.Folder, siteUrl);

                //save the changes to the SSP Content Database
                scopes.Update();

                //start compilation of the scope
                scopes.StartCompilation();
            }

        }

        public override void FeatureDeactivating(SPFeatureReceiverProperties properties)
        {
            
        }

        public override void FeatureInstalled(SPFeatureReceiverProperties properties)
        {
            
        }

        public override void FeatureUninstalling(SPFeatureReceiverProperties properties)
        {
            
        }
    }
}

I've started getting tired of following the steps on Mike Ammerlaan's blog for Integrating ASP.NET AJAX with SharePoint.  It's not that the steps are difficult to follow, but there's a lot of stuff you need to get right if you want to have all the ASP.NET AJAX functionality available in MOSS.

To ease my own pains with this process - and hopefully yours, too - I've published to CodePlex some STSADM extensions for adding and removing the needed ASP.NET AJAX entries to the web.config file.

Much thanks to Gary Lapointe for providing the source code for his STSADM extensions.  It served as a great starting place for me and decreased the ramp-up time for creating my own custom STSADM commands tremendously.

View CodePlex site to download STSADM extensions for ASP.NET AJAX

<update date="6/19/08">

Telerik has released the MOSS compatable version of the RadEditor that places all needed files as class resource files in the _wpresource directory.  They've also made some very nice improvements over the previous release that make extending and customizing the editor very easy.  If you purchase and deploy the Full-Featrured RadEditor, you get ALL of the controls in the Telerik ASP.NET AJAX control suite available to you in MOSS.  Very nice...

</update>

Yesterday I posted about using the new RadControls for ASP.NET AJAX in MOSS, and I started moving the old controls in my current project over to the new ones.  Just now, I found a problem when I was converting the RadEditor from the old to the new.

In the Telerik online documentation for getting started with the RadEditor, they say that in a standard ASP.NET AJAX application, you need to utilize the App_GlobalResources and App_Data ASP.NET folders in order to use the RadEditor.

That's not any different for MOSS.

In the root of your SharePoint Web Application (\Inetpub\wwwroot\wss\VirtualDirectories\YourWebApp) create a folder named App_Data.  Drop in the RadSpell folder from the App_Data folder of the RadControls install directory (C:\Program Files\Telerik\RadControls for ASPNET AJAX Q1 2008).  Then, drop the RESX files from the App_GlobalResources directory located at the Telerik install root into the already present App_GlobalResources directory in your SharePoint Web Application root.

I think there's probably a better a way to do this using a Solution, but I'll worry about that later.  Not sure if we can deploy into those folders via a WSP - I don't think so.  I know there's a public property on the RadEditor that allows you to point to where the RadSpell directory is, but can't find anything for the RESX files.

Also, make sure you add the following line to the HttpHandlers section of your web config file, or else, spellcheck won't work:
<add verb="*" validate="false" path="Telerik.Web.UI.SpellCheckHandler.axd" type="Telerik.Web.UI.SpellCheckHandler, Telerik.Web.UI"/>

Anyway, here's a screen shot of the unskinned and unmodified RadEditor running in my local MOSS environment.  This is not tied into a publishing placeholder, but that's not what I'm using it for right now...

I've been a huge proponent of Telerik because of their very impressive controls, support, and documentation - let alone for the fact they are very easy to use.  Now that I've been working with SharePoint 2007 for a few years, I've found that Telerik's controls fit very nicely into MOSS.  Andrew Connell even created an integration whitepaper and some nice utility EXEs to help package the individual controls into WSPs to deploy them into MOSS.

Then, on April 15 of this year, Telerik released version 2008.1 of their new RadControls Suite for ASP.NET AJAX, formerly named 'Prometheus'.  I purchased my upgrade from the old RadControl suite to the Prometheus controls yesterday, and there was something that I noticed immediately which frightened me a little.  There's only one assembly - Telerik.Web.UI.ddl - and nowhere that I could see on the Telerik site that allowed me to get an individual control.

Uh oh. 

How do I get these amazing controls into SharePoint and start benefiting from that ASP.NET AJAX goodness?  Do I package the whole thing into a WSP? I hope not! That'll be a huge WSP file with all those skins getting packaged up!

I was worried, and started thinking that I was going to be stuck with a legacy version of some great controls, being forced to sit  here watching new versions go sailing past every three months.  No way!!!

I figured that there had to be a way, and if it took a massive WSP, so be it, so I started poking around the new control suite to see how it ticked.  There's no RadControls directory, so AC's walk-through documentation won't work.

I tested the RadSlider locally, and I asked myself, where do the images come from in the control?

I got out my trusty IE Dev Toolbar and took a peak.  I liked what I saw.

WebResource.axd!

Now, I don't care if this image is an embedded resource file or not.  It's not a direct reference to an image, and that's what matters.  What happens if a skin is applied? Where's the image then?

Office2007 skin:

IE Dev Toolbar:

Still a WebResource.axd. Excellent!

So - here's the deal.  Install the entire RadControls EXE which you get via your Telerik account on your SharePoint server.  Deploy the Telerik.Web.UI.dll to your SharePoint application's bin, and add the following line to the SafeControls block in the web.config

That's it...

Then, you can use any control in the entire suite just by adding the following Register tag to the page where you're using it

No more individual control references anywhere! Sweet!

For example - the RadTreeView control:

You can even deploy this inside your custom WSP by using the various Visual Studio project templates available on CodePlex.  I know of three that support deploying other assemblies, so finding them shouldn't be hard.  I'm partial to this one, and I know stsdev is really nice, as well.  You can even reference the Telerik control assembly server-side, too.  Just make sure you set the CopyLocal property of the reference to False.

You won't get IntelliSense for the controls, but as far as MOSS dev goes - what else is new, right?  There's plenty of documentation on Telerik's site to help with the control properties and client-side API.

Here's the new RadSlider with the Office2007 skin running in one of my MOSS environment:

I've started moving over all of the controls in my current project from the old version of the suite to the new version, and there's been some minor changes, but nothing of a pain at all.  The changes I have seen have been good ones, so it's been worth it so far.  Besides, these controls ROCK!  I haven't gone through and seen which ones work and which don't, but I'm sure it'll be similar to the old version of the suite.  I know the RadSplitter was a hassle before, will have to try it again with the new ones.  I've even noticed some performance gains over the old controls.

So, if you haven't picked up on it, I highly recommend these controls.  Not only will they completely expand your MOSS UI potential, but they will get you to install Service Pack 1 and configure ASP.NET AJAX in SharePoint if you haven't yet.  Remember, SP1 is required if you want to use ASP.NET AJAX, therefore, it's required to use these controls.

Having spent a great deal of time developing Microsoft Content Management Server 2002 solutions, I've found there's a bunch of stuff I miss from the MCMS API.  The single thing I miss the most:

CmsContext.Searches.GetByGuid(string) as HierarchyItem;

Being able to get any object - Channel, Template, Posting, Resource - by just it's guid was huge.  Even cooler was that you could grab an object out of anywhere in the hierarchy/taxonomy.  In SharePoint, you have to know the Web, List, and Item guid to find anything.  This one method in MCMS allowed a huge number of possibilities for custom dev with very limited coding time.

Another thing I miss from MCMS is the functionality of Connected Postings/Templates and an API that could CRUD them without hardly any effort.  I know Variations in SharePoint comes close, but IMO, it just doesn't seem to be at the same level and simplicity of MCMS.  Also, there's very little documentation around any of the Variation related objects because they've all been marked as internal.

Luckily, Michiel Lankamp figured this out - a long time ago - using Reflector (duh) and exposed that yes, everything in SharePoint is a list (thanks Matt). As Michiel points out, there's two variation lists. One called VariationSettings and one called VariationLabels who's guids are stored as Properties on the root web of the site collection.

Once you get the lists, how do you create the hierarchy? Check out Michiel's post to see how. Pretty clever...

I haven't tried this, and based on the four comments, not many other people have, either.  Also looks like it could be buggy.

Enable variations programmatically - Michiel Lankamp

So a client came to us today complaining that their SharePoint site was dead.  Looking at the performance monitor revealed that the processor was maxed out.  SQL showed around 1300 active connections.  IISReset and bouncing of the server proved to be of little help.

We shut the firewall off to the outside and were able to get the default page of the site to render without any problems.

After going back and forth troubleshooting the server for most of the morning, we took a look at the site's default page's web part maintenance page which showed a total of 88 web parts on the page, 54 of them being closed and in the Web Part Page Gallery.  All 54 of those web parts were Content Editor Web Parts.

wow

That's a lot of web parts.  According to TechNet, the maximum recommended number of web parts on a page is 50.  What the client had been doing was adding CEWPs to the page and once the content was no longer valid, hitting the 'X' on the web part, closing it, but not deleting it.  Doing so caused SharePoint to still get the web part from the database, just not render it on the page.

According to MSDN documentation titled 'A Developer's Introduction to Web Parts':

A Web Part Page gallery contains Web Parts that are already added to the current page. This may seem paradoxical at first. Why would you need to add a Web Part that is already added to the page? The reason this is useful is that you can add a Web Part to a page and then close the Web Part. To close a Web Part, click the arrowhead on the right side of the Web Part title bar, and then click Close. A closed Web Part is no longer visible on the page, but it is still a member of the Web Part Page gallery for that page. The Web Part is still associated with the page by an entry in the configuration database of the server running Windows SharePoint Services, which also stores any shared or personalized property settings for the Web Part.

You can add a Web Part to a page, personalize it extensively, close it, and then later add it back to the page with the personalization intact. To bring back a closed Web Part, select it from the Web Part Page gallery.

Note   To truly delete a Web Part from a page, you must click the Modify My Page menu (or the Modify Shared Page menu in shared view), and then click Design this Page to add the Delete command to the drop-down menu of the Web Part. To remove the Web Part from the page without adding it to the Web Part Page gallery, click the arrowhead on the right side of the Web Part title bar, and then click Delete.

After removing 50 of the closed web parts from the Web Part Page Gallery, not only was the site back up, but the response time for the page was faster than it has been for quite some time.

When creating a WSP in WSSv3, the common development practice is to create a project in Visual Studio using the Class Library project template.  The problem with this is that none of the Workflow item templates are present when you try and add a new item, so how can you add a Workflow without having a one-off Visual Studio project just for your Workflow Feature?

The answer is that you need to make some changes to the project file in Visual Studio to make it happen.  The project file (YourProject.csproj - for example) is the file which tells the IDE what files, references, folders, etc. are present so that when the project is built, MSBuild knows how to compile the assembly correctly.

The steps I'll walk you through are intended for Visual Studio 2005.  You need to make sure you have the latest version of the Office Server SDK available from MSDN.  The steps are pretty much identical for Visual Studio 2008, you just need to make sure you change the targeted version of the .NET Framework to be version 3.0.

First thing - if you have the project under source control, you want to make sure the project file is checked out or else you won't be able to edit it.

Now, you want to unload the project in the IDE.  To do this, right-click the project and choose 'Unload Project'

Once the project has been unloaded, right-click the project again and choose 'Edit YOURPROJECT.csproj'  This will open the project file for editing in Visual Studio.

Locate the first PropertyGroup in the file at the top, and paste in the following code

<ProjectTypeGuids>{14822709-B5A1-4724-98CA-57A101D1B079};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>

as shown below

Now you need to make sure that the proper references are included

Locate the ItemGroup in the project file with the references

Paste in the following references after the last reference in the ItemGroup

<Reference Include="microsoft.office.workflow.tasks"/>
<Reference Include="Microsoft.Sharepoint.WorkflowActions"/>
<Reference Include="System.Workflow.Activities" />
<Reference Include="System.Workflow.ComponentModel" />
<Reference Include="System.Workflow.Runtime" />
<!-- you probably already have the following -->
<Reference Include="Microsoft.SharePoint"/>

Save the project file and reload the project

Now you have the Workflow item templates available, along with the support of the Workflow designer.

The final step is to change the base class for the Workflows you create. 

If you are creating a Sequential Workflow, you need to make sure the workflow class inherits from Microsoft.SharePoint.WorkflowActions.SharePointSequentialWorkflowActivity.  This will enable the SharePoint Workflow Activities in the Visual Studio Toolbox.  There is no base class for the SharePoint State Machine workflow other than the standard System.Workflow.Activities.StateMachineWorkflowActivity. 

The one main piece of advice I have is to make sure you set the base class of the Workflow class before you start working on it.  When you change the base class, all child activities will be removed from the Workflow.  At least they were removed for me!

Being Asp.Net developers, we all know we can send email from within custom code using the virtual SMPT server running on the Web Front End server where our code is running, but what if you want to use the same SMTP/Exchange settings you configured in Central Administration?

Luckily, there's a way to do so.

I like to create an object I call SPEmail for encapsulation, then within the Send method go dig for the info I need from the SPAdministrationWebApplication.Local and it's OutboundMailServerInstance property.  Once you have these objects, the information entered in Central Admin can be obtained and be used to set up the standard System.Net.Mail SmtpClient and MailMessage objects. 

No messing with the web.config file. Nice.

Here's the code for my SPEmail object:

public class SPEmail
{
    #region Constructors

    public SPEmail() { }

    #endregion

    
    #region Private Members

    string _To = string.Empty;
    string _Subject = string.Empty;
    string _Body = string.Empty;
    bool _HTML = false;

    #endregion

    
    #region Public Properties

    public string To 
    {
        get
        {
            return this._To;
        }
        set
        {
            this._To = value;
        }
    }

    public string Subject 
    {
        get
        {
            return this._Subject;
        }
        set
        {
            this._Subject = value;
        }
    }

    public string Body 
    {
        get
        {
            return this._Body;
        }
        set
        {
            this._Body = value;
        }
    }

    public bool IsHtml
    {
        get
        {
            return this._HTML;
        }
        set
        { 
            this._HTML = value; 
        }
    }



    #endregion

    public void Send()
    {
        string smtp = string.Empty;
        string fromAddress = string.Empty;
        string replyToAddress = string.Empty;

        SPSecurity.RunWithElevatedPrivileges(delegate()
        {
            SPAdministrationWebApplication adminApp = Microsoft.SharePoint.Administration.SPAdministrationWebApplication.Local;
            SPOutboundMailServiceInstance emailService = adminApp.OutboundMailServiceInstance;

            smtp = emailService.Server.Address;

            fromAddress = adminApp.OutboundMailSenderAddress;
            replyToAddress = adminApp.OutboundMailReplyToAddress;

            if (!string.IsNullOrEmpty(this.To))
            {
                SmtpClient mail = new SmtpClient();
                MailMessage message = new MailMessage();
                message.From = new MailAddress(fromAddress);
                message.To.Add(this.To);

                if (!string.IsNullOrEmpty(replyToAddress))
                    message.ReplyTo = new MailAddress(replyToAddress);

                if (!string.IsNullOrEmpty(this.Subject))
                    message.Subject = this.Subject;

                if (!string.IsNullOrEmpty(this.Body))
                    message.Body = this.Body;

                message.IsBodyHtml = this.IsHtml;

                mail.Host = smtp;
                mail.Send(message);                    
            }                
        });
    }
}

So - if you want to write your own, there you go!

Sigh...

After I put this together, I found that you can send email from within the SPUtility object.  SPUtility.SendEmail() will take care of all this for you, too. 

Recently, I've seen a lot (read: too many) posts about the release of SP1 for