Michael Washam's Development Blog

Visual Studio Extensions 1.3 has new features that allow the packaging and deployment of a workflow into a SharePoint Solutions Package (.WSP).

I’m starting off with a real simple workflow. Essentially, when the workflow is activated it will assign a task to a user in my site. It will then wait for the task status to be completed before ending the workflow. For this exercise it doesn’t matter how complex the workflow is or isn’t.

Project Creation

To get started ensure you are running the 1.3 versions of the VSEWSS extensions.
In your workflow solution right click on your existing workflow solution and select Add -> New Project.
Select Language (C# or VB) -> SharePoint -> Empty

You should end up with something like this:

One of the new features of VSeWSS 1.3 is the ability to deploy additional assemblies (such as workflows) without the need for manually manipulating the manifest and moving around files. This will be our next step.

Add the Workflow Assembly for Deployment

Right click on your newly created Empty SharePoint project and click Add Reference -> Browse and browse to the output folder of your workflow. Select the workflow assembly and press OK.

Once the reference is added you will need to manually change the “Copy to Local” property of the reference to true. This is how VSeWSS identifies assemblies that will be included in the package.

Open up WSP View (View -> Other Windows -> WSP View) then click the Refresh tool bar button and open the manifest.xml.
You should see something very similar to this:

Add a new Feature 

To deploy the WF you will also need to deploy the associated configuration files too. For this we will use another new feature within VSeWSS 1.3. The ability to add a new Site scoped feature with an elements.xml file directly from within WSP View.

Open WSP View and click the Add New Feature button.

Within the Feature Scope Settings dialog change the Feature Scope to Site and check Add default element.xml file.

Rename the Feature

Rename the resulting Feature1 to your desired feature name. Highlight Feature1 and press F2. In this example the resulting feature will be named WFToDeploy. Note, if you do not want to keep the Feature1 naming convention on your file system you will need to rename this directory in Solution Explorer as well.

Expand the feature and open the Feature.xml that was created. Find the Title attribute on the feature element and change it to your feature name.

The next step is to incorporate the configuration in your existing workflow.xml into the feature. 

Combining the Workflow.xml into the Element1.xml

Open the created Element.xml you should have something like this:

Remove the closing slash / on the element and add a closing </Elements> below it. Be careful not to remove the Id attribute!

From Solution Explorer open the workflow.xml file within your existing workflow project. Copy the XML starting at <Workflow and ending at </Workflow> in between the <Elements element in the element1.xml file.

The result should be similar to this:

Custom Forms

If you are also deploying ASP.NET or InfoPath forms along with your workflow you will need to add them as Modules to your WSP project.

Deploying the project

Right click on your project and select Build to ensure everything compiles (fix any errors if present).
You now have the option of packaging or deploying. If you right click in select Package your .WSP will be built into the output directory but not deployed. Clicking Deploy will package the .WSP and also deploy it to the specified SharePoint site (specified under Project Settings -> Debug -> Start Browser with URL).

Testing the Workflow

Right click on your WSP project and click Deploy. Now browse to the SharePoint site you deployed to and go to a document library such as Shared Documents. 

Click Settings -> Document Library Settings -> Workflow Settings -> Add a Workflow.

You should see your workflow in the Select a workflow template list.

Give the workflow a unique name and press OK to associate it.
Back in Shared Documents bring up the actions menu for an existing document (create one if necessary) and click the Workflows item.

Start the Workflow

Select your workflow from the list to start.
You should see a new column added to your library with the same name as your workflow. If it successfully started it will have a value of In Progress or Completed (depending on what it actually does). 

Done!

Why does my event receiver / handler run more than once when I update or add a new list item?

There are a few common situations where this can occur. The first and most obvious is when you are handling an ItemUpdated event and within the event you  update the item in question again from your code.  Obviously, without precautions this will trigger another update! (This can happen from other events too such as ItemAdded)

The following function writes an entry to the Application event log everytime it runs. It also checks for a null title or a title that does not equal "Title Updated in ItemUpdated". If it finds either it updates the Title field of the current item.

FYI LogEvent() is just some simple code to log to the application event log:

When I update a field in one of the listitems I see the following logged in the event log (as expected).

The reason it only runs once is because I am checking the title value before I do the update. The 2nd time around the title is the same so the Update() does not occur.

The solution to this problem is very simple: Call DisableEventFiring immediately before you modify the list item and then call EnableEventFiring when you are finished.

The second common scenario for your event receiver running multiple times is having the event handler registered to the same list more then once.

I've ran into this scenario before mostly in developer environments where registration is occuring in multiple ways. For example deploying your event receiver with VSEWSS and then programmatically registering it (again) in a feature receiver.

To detect whether this is going on in your environment you can write a very simple console application to enumerate through the registered receivers for your list.

The output for my test environment after the vsewss/programmatic mix:

You'll notice from the output that my event receiver has multiple registrations for the ItemUpdated() event. This is because my feature receiver programmatically registered this event.. Likely, you'll only run into this scenario in developer environments where there is a lot of experimenting going on but it is a good thing to be aware of.

The output from my event receiver when updating a list item is as expected:

(Note I'm only calling LogEvent in ItemUpdated() not ItemUpdating())

To clean this list up you can programmatically delete the event receivers and re-register.

This example programmatically removes all event receivers from the assembly "BlogSampleDupeER.dll":

There are likely other causes for event receivers running more than once but these are the two that I run into the most while working with customers.

Hope it helps!

STSADMExtractFiles is a sample application that extends the STSADM.EXE command line via the ISPStsadmCommand interface and adds three new commands to the tool:  savefile, savefromfolder and restorefile. The purpose of the sample is to show how an application could be built to extract content out of a SharePoint content database to the file system in order for the content (aspx files etc..) to be saved into a source control system.

These commands allow the user to save content from a SharePoint site directly to the file system and restore a file back to the SharePoint.

The sample uses the WebPartPagesWebService (from _vti_bin/WebPartPages.asmx) to retrieve the file content. This is the same web service that SharePoint Designer uses. The sample uses Regular Expressions to remove some of the SPD specific attributers when saving the file. For restoring the file it uses the FrontPage RPC put_document command.

Supported Commands:

The SaveFromFolder command allows you to point to a starting folder and extract all of the files recursively to the file system.

The following examples demonstrates a JavaScript client calling into a WCF Service which allows updates of SharePoint list data. All deployable from a SharePoint solution (WSP).

The first thing you'll need is the .NET Framework 3.5 installed on your SharePoint server (or VS.NET 2008).

.NET 3.5 Install

http://www.microsoft.com/downloads/details.aspx?FamilyId=333325FD-AE52-4E35-B531-508D977D32A6&displaylang=en

.NET 3.5 SP1 Install

http://www.microsoft.com/downloads/details.aspx?FamilyId=AB99342F-5D1A-413D-8319-81DA479AB0D7&displaylang=en

The second step is to configure the web.config file of your SharePoint site to load the correct assemblies.

In the <configSections> element add the following:

In the <assemblies> section add the following:

In the <pages> section add the following:

In the <httpHandlers> section add the following:

In the <httpModules> section add the following:

Immediately before the </configuration> element at the bottom of the web.config add the following:

Note the <system.serviceModel> element. This is the configuration for the WCF service we are about to add.

The next step is to actually create the web part. Create a new SharePoint web part project named DynamicWCFPart (I'm using the Visual Studio Extensions for SharePoint 1.2) but you can use whatever you want :)

Once the webpart project is created change everything you see from WebPart1 to MyDynamicPart (you will need to go into WSP view and change this part too). 

Next add a new SharePoint Template. Name the template item MyWSSListService.svc.

Beneath the Templates directory in Solution Explorer create a new folder called LAYOUTS and beneath LAYOUTS create another folder called MyDynamicWCFPart. Drag the MyWSSListService.svc into the MyDynamicWCFPart folder.

The next step is to add another SharePoint Template to your project. This time name it MyDynamicPartCtrl.ascx. This will be the UI of the webpart.

Once the template is added expand the Templates folder and create a new folder beneath it called CONTROLTEMPLATES then create another folder called MyDynamicWCFPart. Drag the MyDynamicPartCtrl.ascx into the newly created MyDynamicWCFPartfolder.

Finally, your solution should look similar to this:

To get your site ready you will need to create a custom list in your SharePoint site called Clients. The custom list should contain the following fields: Title (the existing one), Address,  City, State and Zip. All of the fields will be of type "Single Line of Text". You should also add some test data into the list as this webpart sample only edits (no inserts).

Next, add the following references:

System.Web.Extensions (3.5.0.0), System.ServiceModel (3.0.0.0), System.ServiceModel.Web (3.5.0.0), System.Runtime.Serialization (3.0.0.0).

Next we'll actually create the WCF service. We'll add the code inline to the .svc file that way it is deployable along with our webpart.

Finally, you should build your project to make sure you have all of the references correct.

A few things to note about the WCF service. First, in order to get a reference to the SPContext object correctly the service's class needs to have the [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)] attribute added. The second thing to note is the ClientInformation class. It is marked with the [DataContract] attribute along with its members marked with [DataMember] so WCF will know to serialize this to our our client.

Our next step is to add our user interface. Since there is quite a bit of JavaScript involved here I felt it would be easier to design the UI in an ASP.NET User Control (.ASCX).

Open the MyDynamicPartCtrl.ascx control in Visual Studio and paste in the following code:

This is definitely not the fanciest UI possible :) What it does is essentially gives you a dropdown list of "clients" to edit. Once you select a client and click the "Edit Client" button the service method GetClient is called. OnClientSelected is the callback when our client is retrieved. From there I populate and show a small form to allow the user to update the list data via the UpdateClient() service method.

To display the user control within the webpart we'll need to dynamically load the control and insert it into the control tree. Open MyDynamicPart.cs and add the following code to your CreateChildControls() method.

The next step is actually a compatability workaround to ensure SharePoint and WCF work well together. For details on the compatability issue see Gille's blog entry here: http://blogs.msdn.com/gzunino/archive/2007/09/17/hosting-a-wcf-service-in-windows-sharepoint-services-v3-0.aspx.

Add a a new C# class to your project and name the file: MyWCFVirtualPathProvider.cs. Replace the code with the following:

Next we're going to create an HttpModule to register the virtual path provider we just created. Add another C# class to your project and name it MyWCFPatchupModule.cs. Replace the code with the following:

You will need to add one more entry to the web.config file of the SharePoint site.

Note you can find your public key token by bringing up a Visual Studio command prompt and from your projects \Debug directory running the following command: sn -T DynamicWCFPart.dll

Deploy your project by right clicking on your project and selecting Deploy.

The next step will be to put your page into edit mode by clicking Site Actions -> Edit Page. Select a zone and click Add a Web Part. Under the miscellaneous category you will see your part MyDynamicPart Web Part. Select it and click Add.

If everything worked you should have something that looks like this.

If you are looking at the various blog entries regarding IRuntimeFilter and are left wondering why it is considered a “deprecated” interface in SharePoint 2007 wonder no more! The functionality of IRuntimeFilter is not gone forever it has just been updated with newer functionality in IRuntimeFilter2. The primary functionality difference between the two interfaces is instead of implementing the filtering UI in a separate ASP.NET dialog you are now able to implement this directly in your very own web control.

This entry goes into detail on how to use this new interface. To save time I’ve borrowed the implementation of IRuntimeFilter created by Michael O’Donovan at http://blogs.msdn.com/modonovan/archive/2005/07/07/436394.aspx and updated it for IRuntimeFilter2.

The first major difference you’ll find between the two interfaces is with the InitializeStrings method.  The original implementation defined the title, tooltip, button text and dialog sizing properties for a custom dialog you build and specify with the BuilderURL attribute in the <RuntimeFilter element of the web.config.  (Note: The BuilderURL is no longer needed in implementations of IRuntimeFilter2)

IRuntimeFilter (Original)

public ArrayList InitializeStrings(CultureInfo cultureInfO)

{

 ArrayList strings = new ArrayList();

 strings.Add("Role Picker");

 strings.Add("Lets you pick which user roles can view this web part");

 strings.Add("Pick Role");

 strings.Add("dialogHeight:340px;dialogWidth:430px;help:no;status:no;resizable:no");

 return strings;

}

With IRuntimeFilter2 you only need to specify the title for your new web control.

IRuntimeFilter2

public ArrayList InitializeStrings(CultureInfo cultureInfO)

{

ArrayList strings = new ArrayList();

strings.Add("Choose Groups To Filter");

return strings;

}

The only new method in IRuntimeFilter2 is GetToolPaneControl(). This method is called by SharePoint to get an instance of the WebControl you are specifying for the user interface of the filter.

#region IRuntimeFilter2 Members

public IToolPaneControl GetToolPaneControl()

{

DevConWebControl.RFWebControl rfwc = new DevConWebControl.RFWebControl();

rfwc.ID = "ID_RDWebControl";

return rfwc;

}

#endregion

The implementation of RFWebControl is relatively straightforward. To keep things simple I’m only filtering on the current sites available groups but you can filter on anything.

    public class RFWebControl : WebControl, IToolPaneControl, INamingContainer, IPostBackDataHandler

    {

        // The listbox that holds the groups available for filtering

        ListBox lb;

        // Custom list entry so I know when the user wants to clear the filter

        const string CLEARVALUE = "Clear Filter";

        protected override void CreateChildControls()

        {

            base.CreateChildControls();

            lb = new ListBox();

            lb.ID = "ID_lbSelectedGroups";

            lb.SelectionMode = ListSelectionMode.Multiple;

            lb.Items.Add(CLEARVALUE);

            // Get the available groups available to filter on

            foreach (SPGroup spg in SPContext.Current.Web.Groups)

            {

                lb.Items.Add(spg.Name);

            }

            this.Controls.Add(lb);

            // Initialize listbox if there were groups previously selected

            if (Text.Length > 0)

            {

                String[] groups = Text.Split(new char[] { ',' });

                foreach (String g in groups)

                {

                    foreach (ListItem li in lb.Items)

                    {

                        if (g.CompareTo(li.Text) == 0)

                            li.Selected = true;

                    }

                }

            }

        }

        protected override void OnPreRender(EventArgs e)

        {

            base.OnPreRender(e);

            // Register for postback so we can extract the selected

            // groups out in time to hand off to SharePoint

            this.Page.RegisterRequiresPostBack(this);

        }

        #region IToolPaneControl Members

        // This is our implementation of IToolPaneControl

        // SharePoint uses this value to persist the selected filter

        String _filterText = "";

        public string Text

        {

            get

            {

                return _filterText;

            }

            set

            {

                _filterText = value;

            }

        }

        #endregion

        #region IPostBackDataHandler Members

        bool IPostBackDataHandler.LoadPostData(string postDataKey, System.Collections.Specialized.NameValueCollection postCollection)

        {

            String controlID = "ID_lbSelectedGroups";

            String fullID = "";

            // Loop through the controls until we find our listbox

            foreach (String k in postCollection.Keys)

            {

                if (k.Contains(controlID))

                    fullID = k;

            }

            if (postCollection[fullID] != null)

            {

                // This will contain the groups selected by the user

                // So we need to set the Text property with the filter

                Text = postCollection[fullID];

                // If the user selected clear empty the filter

                if (Text.CompareTo(CLEARVALUE) == 0)

                    Text = "";

            }

            return true;

        }

        void IPostBackDataHandler.RaisePostDataChangedEvent()

        {

        }

        #endregion

    }

The other major difference in the IRuntimeFilter2 implementation is since I’m filtering on groups stored in comma separated values my utility function CanUserSeePart() is different.

private bool CanUserSeePart(string groups)

{

        SPUser spu = SPContext.Current.Web.CurrentUser;

 

        String [] tmpGroups = groups.Split(new char[] { ',' });

 

        foreach (String g in tmpGroups)

        {

            foreach (SPGroup spg in spu.Groups)

                if (g.CompareTo(spg.Name) == 0)

                    return true;

        }

        return false;

}

To try this sample out on your own download the project from the post attachment. Once the solution is built you will need to register both DevConRuntimeFilter.dll and DevConWebControl in the global assembly cache using gacutil –i DevConRuntimeFilter.dll and gacutil -i DevConWebControl.

You will need to register your filter in the web.config of your SharePoint site. Keep in mind there can only be one RuntimeFilter per virtual server so if you are testing on a MOSS install you will need to comment out the original AudienceManager filter before adding this one.

The safest place to register your filter is immediately before the ending SharePoint element </SharePoint>.

 <RuntimeFilter Assembly="DevConRunTimeFilter, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b9e17e23dc48e734" Class="DevConRunTimeFilter.RuntimeFilter" />

Run IISReset and you should now be able to see the sample when you bring up the “Modify Shared Web Part” menu.