From feeling to insight

Just a few quickies in case you want to export a SharePoint Designer Workflow straight into Visual Studio there are a few things that might save you quite some time. In this blog I try to cover the things I encounter.

First of all, if you want to import your globally reusable workflow using the Import Reusable Workflow you need to make sure it is published. If your workflow is not published before it’s saved as a template it will not be recognized in the import wizard, thus making it impossible to import it.
When creating the workflow with the SharePoint designer it is pretty easy to give a fancy name to the workflow, in my case it was called Provisioning Approval Workflow, saving it as a template doesn’t throw any error, then importing seems to work, however as soon as you try to package the new project it starts throwing errors like:
Activity 'RootWorkflowActivityWithData' validation failed: Property 'Name' has invalid value. The identifier  '' is not a valid name.   
So the x:Name attribute is not supporting a space in the name, that’s an easy fix, by changing it, however after doing so the assembly building fails because it tried to make a class called: 
public partial class Provisioning Approval Workflow

You can start fixing those issues one by one, but also just before publishing and exporting the workflow replace any spaces in the name for _ so everything will compile right away.
Now there is one more minor thing before the project actually builds, it is missing references.

If you have custom workflow activities that might be expected behavior (just add them), but by default it is also missing the Microsoft.SharePoint.WorkflowActions. That one can be found on the location: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI\Microsoft.SharePoint.WorkflowActions.dll
and after adding that your imported workflow will most probably compile.

Once it compiles you might want to change the feature name because it still has a default Feature1 name. Also you might want to check the Elements.xml file in the Workflow object for the Name and Description (in the Name you can strip out any _ and return it as a fancy name. Also you can probably strip out the whole <MetaData> block since that contains almost only empty elements (except for the StatusPageUrl that, if you don’t roll-out a custom StatusPageUrl can be left blank to get the default one). Also you can strip out the InstantiationUrl , ModificationUrl and StatusUrl since they will throw errors when executing the workflow (throwing an error like: The workflow template has specified no FormURN for this page.). If you don’t throw out the MetaData block make sure to delete the AssociationCategories node because otherwise provisioning the Workflow to a ContentType.

Colligo allows you to sync SharePoint lists and libraries to your computer, and since Office 2003 won’t recognize memberships pulled from a SharePoint 2007 environment by default, one of your customers choose this tool to have a save-as functionality option in Office 2003. The idea was to auto generate the xml file that is readable by Colligo so each user would have a set of sites to save to.

First things first, the documentation on how you can create such an xml file can be found here  and a demo xml file can be found here (xsd can be found here). Knowing that makes it pretty easy to generate the xml you require. Two things to keep in mind:

• Don’t use comments in your XML file, Colligo just won’t import it.
• If you auto generate the xml multiple times, make sure to delete the file after Colligo imported it, otherwise it tries to import it again (and fails) the next time you start Colligo

So creating XML files for Colligo made easy.

Building code that retrieves memberships most of us will do by using the Publishedlinksservice that returns all the memberships. However normally those memberships only update every hour, so if you have a development machine and you want to test code (or check whether the memberships actually get updated), you are stuck waiting. Sadly you cannot force an update on the timer job that syncs those memberships; luckily you can speed up things, the STSADM sync operation allows you to set the time it takes between syncing.  So the next command will force the timer job to sync every minute:  

stsadm -o sync –SyncTiming M:1

This might cause some load, but on my development machine I don’t really care about that, as long as I can see results. And of course you can set it back to its original 60 minutes afterwards.

Last few days I have been struggling with a piece of code that should update a UserProfile. The idea was to make a nice feature that allows a WebPart to display a link that would open a screen showing the user some options to change UserProfile values. Those change options should be rendered based on three pieces of information; a Site Column containing possible values, a ControlType and the UserProfileProperty to save it to.

The first few versions worked pretty well since I only had to save strings or checkboxes, however further along the way I decided that ChoiceLists from the UserProfile should be supported, and there it all went wrong, even with Google it took me quite some time figuring out how to do it, so here a few tips: 

Saving a single value to a UserProfileProperty even when its a ChoiceList is pretty easy:

    userprofile[item.Key].Value = item.Value;

Saving multiple values to a userProfileProperty took me some more time, but finally even that appeared to be possible:

   foreach (string choice in choiceList)
   {
      userprofile[item.Key].Add((Object)choice);
   }

Minor detail on that part appeared that the .add option does as it says, it only adds items; ergo if you would already have selected option1 in your profile, and try to update it with an option2, it would keep the option1 saved, and adds the option2.

So before you are actually try to save values that way do a:

   userprofile.clear();

   userprofile.update();

Now that’s for ‘saving’ values to your UserProfile, reading them is another story, reading a ‘normal’ string can be done with a simple:

   userprofile["PropertyToRead"].Value;

Reading a ChoiceList should be done like:

   if (userprofile["PropertyToRead"] is UserProfileValueCollection)
            clValue = userprofile["PropertyToRead"] as UserProfileValueCollection;

Whenever you done that you can simple loop trough the UserProfileValueCollection for reading the selected items.

Today I found myself running into the ‘famous’ “The security validation for this page is invalid” error and it cost me quite some stress figuring out what went wrong, and why I wasn’t allowed to do what I wanted, a simple change to a user profile.

The thing is that everything worked fine, until I actually added the UserProfile.Commit() to apply the changes to my profile. So after some searching the web for something that could help me further (besides the run with elevated privileges), and some help from my colleague Peter we found the following article: The security validation for this page is invalid.

Basically the idea is: forget the AllowUnsafeUpdates(); and add a FormDigestControl to the page you are working on, as you can see it only takes a reference: 

<%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

And a control:

<SharePoint:FormDigest runat=server/>

Further info can be found on the mentioned blog.