static void Main(string[] args) {
    SPSite siteCollection = new SPSite("http://server");
    SPWeb site = siteCollection.OpenWeb();

    // do something
}

using (SPSite siteCollection = new SPSite("http://server")) {
    using (SPWeb site = siteCollection.OpenWeb()) {
        // do something
    }
}

SPLimitedWebPartManager manager = defaultPage.GetLimitedWebPartManager(PersonalizationScope.Shared);

using (SPLimitedWebPartManager manager = 
       defaultPage.GetLimitedWebPartManager(PersonalizationScope.Shared)) {

    // do something

    if (manager.Web != null)
        manager.Web.Dispose();
}

public void GetListItemsFromSiteMapProvider() {
    using (SPSite siteCollection = new SPSite("http://server")) {
        using (SPWeb site = siteCollection.RootWeb) {
            string listName = "ListName";
            string camlQuery = "<Where><Eq><FieldRef Name='Title'/><Value Type='Text'>Value</Value></Eq></Where>";

            SPList list = site.Lists[listName];
            SPQuery query = new SPQuery();
            query.Query = camlQuery;

            PortalSiteMapProvider provider = PortalSiteMapProvider.CurrentNavSiteMapProviderNoEncode;
            PortalWebSiteMapNode node = provider.FindSiteMapNode("/") as PortalWebSiteMapNode;                   
            SiteMapNodeCollection results = provider.GetCachedListItemsByQuery(node, listName, query, site);

            foreach (PortalListItemSiteMapNode item in results) {
                // do something for each item
            }

            site.Close();
        }
        siteCollection.Close();
    }
}

Lately I have been answering a number of questions related to workflows, specifically what you can and can't do with SharePoint Designer (SPD), and what advantages a custom Visual Studio workflow has over one created in SPD.  Basically, there are 3 ways to implement a workflow for SharePoint: use an out-of-the-box workflow, build a custom one using SharePoint Designer, or build a custom one from scratch using Visual Studio.  99.9% of the time, we eliminate the first option right away, as our clients rarely need something as simple as what the included workflows provide.  The following is a description of what's possible with the other 2 options, and how to make the right decision for which one to use.

 

SharePoint Designer

SharePoint Designer is obviously the preferred choice for creating workflows that need to do basic things, such as sequential document approvals, sending emails, creating tasks, etc.  The workflow designer wizard is user-friendly and easy to use, and attaching a workflow to a list or library is a cinch.  However, if you need to do something that's not given to you in the wizard, you don't really have much of an option other than to fire up Visual Studio and develop something custom.  Let's take a look at some of the things SPD can't do...

#1. [Lack of] Reusability
The most frequently mentioned limitation of SPD workflows is the inability to reuse them.  These workflows are bound to a list and site at design time through the workflow designer wizard, which does not offer the ability to publish to multiple locations.  This can potentially be overcome with manually copying the source files and updating the list and field ID's in the XML manually as described here, but this is extremely error-prone and not always effective.  I've seen cases where the source files were copied manually, the ID's were updated, the workflow republished, and the workflow still did not fire.  I didn't spend a significant amount of time troubleshooting it, just be aware that this is not a supported method of reusing workflows, and may not always work.

#2. Limited Conditions and Actions
With SPD you're basically limited to what is provided with the workflow designer wizard.  You're given a handful of conditions and a handful of actions, and that's what you have to work with if you're unwilling to write any code.  The included conditions and actions are simple and straight-forward and do not offer any customizations. Some of things that one might think SPD is capable of doing out-of-the-box, but can't:

• Accessing Active Directory information directly, such as manager name or email
• Kick off another workflow
• Remove or grant permissions on the list item
• Remove or grant permissions on a list, library, or site
• Copy/move list items to a list in another site
• Send emails with attachments
• Jump to, or return to, another step in the workflow
• Access information or content of the actual document in a document or form library -- SPD can only see the list columns.
• Create or delete lists, libraries, sites
• Wait for an item to change for a maximum amount of time

#3. No State-Machine Workflow Support
Workflows usually fall into one of two categories: sequential and state machine.  A sequential workflow is one that runs through all the steps and actions in sequence, one after another.  This may include parallel activities, where a bunch of people receive an email at once, for example, but the workflow as a whole runs from start to finish.  A state machine workflow represents a set of states, transitions, and actions. One state is denoted as the start state, and then, based on an event, a transition can be made to another state. The state machine would have a final state that determines the end of the workflow.  A state machine workflow is typically used when a particular step in a workflow needs to be repeated, such as during an approval process.  Take for instance the following scenario I encountered at a client:

A form to approve a product was created and submitted to a SharePoint form library.  This form when initially submitted needed to be routed to the requestor's manager.  The manager has the option to approve it and forward it on to the pricing manager, or reject it and send it back to the requestor, in which case that portion of the workflow would start over again, and would follow the same approval process.  If approved and sent to the pricing manager, this person would have the option to approve the form, send it back to the requestor, send it back to the manager, or send it back to both parties.  Yyyyeah...SPD can't do that.  There isn't a handy "Jump to Workflow Step" action.  The solution that was provided to the client was to handle a lot of the logic in the InfoPath form itself which used a decent amount of managed code in the form itself for some of this. All SPD was used for was to send emails.

In conclusion, if the workflow requires steps to be repeated, look elsewhere other than SPD.  If you're using an InfoPath form, you may be able to throw in enough logic there to do what you need, and if not a Visual Studio workflow may need to be explored.

#4. Limited User Data Collection
SPD provides a Collect Data From a User action that allows will create a task in the Task List and allow you to provided fields for the user to provide simple information.  For example, a single line of text, a checkbox, a drop-down list with pre-defined values, etc.  This creates an associated ASPX with custom SharePoint controls and logic, and cannot easily be modified.  In addition, you can't code the ASPX page to do anything custom in conjunction with the workflow, such as provide a drop-down list populated with SQL data, then use that elsewhere in the workflow.  Once again, you're limited to what you're given here.  A similar SPD action is Assign a To-Do Item, where you're able to specify some text which will create a task for a person and use the value you specify as the Task title. 

What's nice about a Visual Studio workflow is you are able to assign a custom task form to a task, which can be used to collect data.  This can be an InfoPath form or a custom ASPX form, and can contain custom code and logic, and the usual InfoPath and ASP.NET controls, respectively.  You can do whatever logic and data presentation you need to do, and are not restricted to what's provided out-of-the-box with SPD.

#5. Task/Action Dependencies
Another item not often thought of is the dependence of a task to the action that actually needs taken.  For example, a task can be created that says "Review this form and update some value", but how does the task know when it's completed?  If you bypass the task completely and go to the form and update the values and save it, the task will have no idea that the form has been updated.  Likewise, if you just complete the task without actually doing anything, it doesn't ensure that you did what you're supposed to do.

Since you control every step of the workflow in a custom VS workflow, you can enforce this dependency.  Do not provide complete buttons on your task forms, and leave it up to the running workflow to check the status of the submitted form and update the associated task accordingly.

These are just a few of the main points that continuously come up when designing workflows, and assessing whether or not SPD is the right tool.  Luckily, we haven't had many requests to provide the aforementioned functionality, so we've been able to make SPD jump through enough hoops to provide what they've needed.

When to Use SharePoint Designer
So, when is it a good idea to use SPD?  The answer is all of the time unless you absolutely can't.  If you can do it in SPD cleanly (key word being cleanly), then I recommend you do.  You won't find an easier way to create a simple task, send an email, or associate the workflow to a list, and you shouldn't recreate the wheel if the functionality is provided for you already.  If you need to do one of the items described above, or if you find yourself creating many individual workflows for the same "workflow", or if something you need to do can only be done using custom code, then consider writing a custom SPD activity or creating a workflow in Visual Studio.  Read on to find out if these other options are the right choices.

 

Custom SharePoint Designer Workflow Activities

As already mentioned, SPD gives you a handful of conditions and actions ("activities") out-of-the-box.  There are a ton of actions that I think should be included, but aren't.  Luckily, a framework is in place that allows developers to design their own SPD workflow activities, deploy them to a server, and have them be accessible to all workflows created in SPD.

Through a little bit of coding, configuration, and deployment, you are able to build your own activity that will appear in the SPD workflow designer wizard as an action.  This is plenty useful if you foresee a need to provide missing functionality to variety of workflows, such as an Active Directory lookup, or the ability to create sites or lists on the fly within a workflow.  Custom activities should only be considered when #1. the functionality isn't already included as an SPD action, and #2. the custom activity can be used for more than one workflow.  Custom activities are deployed globally, so it's not a good idea to create one specific to a single workflow, because there's nothing stopping other users of SPD from using it on one of their workflows, potentially screwing something up or doing something unintended.

Limitations of Custom SharePoint Designer Activities
While you can do almost anything with .NET code (and custom activities are written in .NET), you're still bound to the limitations imposed by the SPD workflow design process.  You still can't write an action to jump to a particular step in the workflow, you still can't have the workflow run as another user (you can run your custom activity as another user, however), you still can't move SPD-authored workflows around easily, etc.  You can do whatever you want for that particular action in that particular step of the workflow, but you're still constrained to using the SPD workflow designer.

When to Use Custom SharePoint Designer Activities
Custom activities are a nice middle-ground between what you're given with SPD by default, and building a workflow from scratch using Visual Studio, but keep in mind they serve a very specific purpose: to provide common functionality to all workflows.  Since they're available in the wizard, they are able to be used in any workflow.  If you haven't picked up the point yet, do not create a custom action that shouldn't be used by more than one workflow!

Useful SharePoint Designer Custom Workflow Activities
Luckily, other developers have seen the light when it comes to custom activities, and have built a few useful ones to address some of the missing functionality described above.  The following activities can be downloaded here:

• Send Email with HTTP Attachment
• Send Email with List Item Attachments
• Start Another Workflow
• Grant Permission on Item
• Delete List Item Permission Assignment
• Reset List Permissions Inheritance
• Is User a Member of a SharePoint Group
• Is Role Assigned to User
• Lookup User Info
• Copy List Item Extended Activity
• Send Email Extended

 

Visual Studio Workflows

All workflows used in SharePoint rely on Windows Workflow Foundation (WWF), which is a piece of .NET goodness introduced in version 3.0.  Whether it's an out-of-the-box workflow, or SPD-authored workflow, they're all powered using this technology.  The difference with those 2 options versus creating one yourself in Visual Studio is most of the leg work and overhead is already done for you.  With Visual Studio it's up to you, the developer, to code every single thing that needs to happen during the workflow.  It's important to note that by creating a custom workflow in Visual Studio, it's not going outside the bounds of an appropriate workflow-creation tool -- Visual Studio is just another tool to use to create SharePoint workflows, and a very powerful one at that.

What's wonderful about a workflow created from scratch is you're given all the power to decide what you want the workflow to do.  You're not bound to certain conditions or certain activities like you are with SPD.  In addition, some workflows (like a state-machine workflow) aren't even possible in SPD, so Visual Studio must be used.

Visual Studio workflows also enable you to use custom forms at certain points in the workflow.  A custom InfoPath form or ASPX page can be written to display or collect any information that you want, and have that integrated into the workflow.  For example, if you need to collect information or provide user-configurable options when assigning a workflow to a list, you can develop an association form that collects this data. If you need to collect information when the workflow is kicked off for a particular item, you can implement an initialization form.  You can even collect information during the workflow using custom task forms.  For workflows that need a significant amount of user-provided data during the workflow in order to make decisions inside that workflow, Visual Studio will probably need to be leveraged to provide a custom form for that data collection.

Finally, Visual Workflows are reusable and moveable.  They're implemented as SharePoint Features, and only need installed and activated on whatever SharePoint environment you're using.  You assign the workflow to a list at runtime, not design time like you do with SPD.  You can use the same workflow on 100 different lists if you need to.  In SPD, you would have to recreate that same workflow 100 times, or make 100 copies of the workflow in order to achieve this.

Drawbacks of Visual Studio Workflows
Obviously the drawback to building a custom workflow in Visual Studio is the time it takes to do so.  With the out-of-the-box and SPD-authored workflows, so much of the initial overhead is done for you, and it's easy to take that for granted.  It's up to you to decide exactly what is supposed to happen, how to get the data from the list item as needed, and make the decisions in the workflow.  Visual Studio uses a number of activities that help facilitate this, but it is a time-consuming and cumbersome process.

Another drawback is implied from the first: only developers have the ability to create these workflows.  An advantage of an SPD workflow is that business users are [usually] smart enough to create them, and don't need to contact IT or a developer to do it for them (yes, I know what I just said, but that's the intended use of SPD...)

When to Use Visual Studio Workflows
The default answer for this is....use a Visual Studio workflow when you can't do something with an out-of-the-box workflow or with SPD.  If you need to implement a state-machine workflow, or you need to collect a lot of complex information from a user during the workflow, or you need to reuse a workflow over and over again, etc., then you should build it in Visual Studio.

This next answer should have as much weight as the previous...build a Visual Studio workflow if it will result in a better-architected, cleaner solution.  It may very well be possible to accomplish something using a combination of SPD workflows and a handful of custom actions, but rarely is that good design.  By having multiple moving parts, you're introducing multiple points of failure that each have to be maintained.  It is better to force a good solution than to force a particular tool on a client.

 

So, How Do I Choose?

Great question!  The answer is easy -- do the simplest thing possible that will result in a clean solution.  If you can implement the requirements with an out-of-the-box workflow, use that.  If you can implement the workflow in SPD using the included conditions and activities, use that.  If you can use SPD for all but one tiny thing that could be addressed by a reusable activity, build one and use SPD.  And if you can't provide the requirements in a clean, maintainable solution using SPD, then build it in Visual Studio.