If you are using STSDEV to create your workflow templates, I bet you’ve run into errors (Most common being “Could not resolve field type”) when executing workflows that reference the workflowProperties object. Turns out that STSDEV does not bind the workflowProperties object to the SPWorkflowActivitationProperties object during activation.
In order to resolve this problem, simple add a OnWorkflowActivated event control to the workflow (if not already present) and under Properties, bind the workflowProperties object (member in your workflow class) in to the WorkflowProperties property (control in workflow) as show below.
(Click image for full size)
If you have tried to develop custom definitions/features for SharePoint in Visual Studio (using VSeWSS) and have run into one of the following errors, it’s most likely you have not completed the post-installation checklist.
The content type text/html; charset=utf-8 of the response message does not match the content type of the binding (text/xml; charset=utf-8).
This error is mainly due to the WCF HTTP Activation feature not being enabled. Go to you’re Server Manager (or Control Panel -> Add Windows Features) and Install the WCF HTTP Activation feature under .Net Framework 3.0 Features.
After enabling the WCF HTTP Activation feature, if you run into the following error, chances are the service account running the SharePoint Central Administration v3 Application Pool does not have local admin access to the machine you’re trying to deploy to.
VSeWSS Service Logging Error: Access to the path ‘C:\Windows\system32\config\systemprofile\AppData\Roaming\Microsoft\VSeWSS 1.3’ is denied.
Logging failed attempting to write to C:\Windows\system32\config\systemprofile\AppData\Roaming\Microsoft\VSeWSS 1.3\VSeWSS1.3 service.log. This may occur because the VSeWSS WCF Service does not have local administrator permissions.
To fix this error, you need to provide admin access to the service account running the application pool. Most folks have suggested the use of Network Service to run SharePoint Central Administration which is not a good practice (and should be avoided, specially in a production environment). The best way to workaround this is to create a new Application Pool called “VSeWSS” in IIS. Go to Advanced settings in the AppPool and set the Identity to your local admin account. Now, under Sites, select “VSeWSS” and click on Advanced Settings. Change the Application Pool from “SharePoint Central Administration v3” to “VSeWSS” and perform an IISRESET.
You should now be able to deploy your custom features within Visual Studio without a problem.
