I spent most of the nineties  in the C++ world with the venerable MFC (Microsoft Foundation Classes) , ATL(Active Template Library) & its famous smart pointers.

I recently had to answer a question in the Sharepoint newsgroups related to using Sharepoint dlls in C++:  I jumped on it as a kid in a candy store (to be honest my current candy store is Sharepoint 2010).

This is what I did:

Create a new CLR Console Application project :

The following code is generated :

Add a reference to the Microsoft.Sharepoint.dll :

Define the Microsoft.Sharepoint namespace:

Write your C++; since Sharepoint classes are managed classes, you have to use the new gcnew operator and you don’t have to call delete.

Run the application :

Don’t forget, Visual C++ is the only compiler that allows you to mix-up managed and native code (we call that IJW or “It just works”); and this without the overhead of the PInvoke layer.

This is quite simple, but it’s not your grandma’s C++ compiler anymore.

I just added a small fix (workflows in content types bug). Enjoy!

Several Sharepointers notice that using the CreateTask activity alone in a Sharepoint workflow doesn’t really create a Sharepoint Task: To have the task created (in the task list) you need to have an activity that will move the workflow in waiting state ; any activity implementing the IEventActivity interface will do the job; that is the case of all sharepoint activities having name starting with “On” (OnTaskCreated, OnTaskChanged,OnTaskDeleted,…), and also the Delay activity.

The Sharepoint activities modifying the Sharepoint content database are enrolled in a transaction which is committed when the workflow persists.

The following setting in the web.config file specifies the Transaction timeout duration:

<configuration>

  <system.transactions>

    <defaultSettings timeout="00:05:00"/>

  </system.transactions>

</configuration>

By default the value is set to 1 minute.  You can increase the value to 5 minutes if you face the following error, which can happen if yoy create several hundreds of tasks :

Workflow Infrastructure             72fg     High    Error in persisting workflow: System.Transactions.TransactionAbortedException: The transaction has aborted. ---> System.TimeoutException: Transaction Timeout     --- End of inner exception stack trace ---     at System.Transactions.TransactionStateAborted.CreateAbortingClone(InternalTransaction tx).

Spending a lot a time (anwering) in the Sharepoint newsgroups, I've noticed the "Failed On Start" error is an extremely frequent question.This post will probably help many people.

When we start a (Custom) Sharepoint Workflow (but even sometimes Out of the Box workflows) the infamous Failed on start (retrying) error may hit you.The most common reasons of this error are:

1. in most cases the main reason is that the CodeBesideclass and the CodeBeside assembly in workflow.xml don't match the workflow class name & assembly strong name  of the dll registered in the GAC  ("Unexpected Load Workflow Assembly: System.IO.FileNotFoundException: Could not load file or assembly xxxx") is what you will find in the Sharepoint log.

User Reflector the compare your assemblies strong name/class name & don't forget the namespace!

2.the workflow-eventdelivery-throttle parameter is to low

To prevent web front ends (w3wp) from getting overrun by running too many workflows instances, there is a throttle limit. If more events than the throttle are already being processed, the newer events are enqueued as work items – they will be picked up by OWSTimer.

If your workflows don’t start immediately as expected you probably have to increase this throttle limit

stsadm -o setproperty -pn workflow-eventdelivery-throttle -pv "20"  (the default value is 15).

By Code :

SPWebApplication myWebApps = SPWebApplication.Lookup(new Uri(websiteUrl));
            myWebApps.WebService.WorkflowEventDeliveryThrottle = 20;
            myWebApps.WebService.Update();

It looks like in some situations” a Failed On Start” may be triggered and can be solved by increasing this value.

In some cases, I’ve noticed that increasing this value may solve a “Failed On Start” which indeed is very strange : when the W3P.exe is overrun, all actions (including event deliveries) are supposed the be enqueued (and thus executed later) but the OWSTIME.exe service.
The error message in the Sharepoint log looks like this:

Windows SharePoint Services     Workflow Infrastructure         936r    Verbose        RunWorkflow: No pending events - possibly targeted for async delivery

3.the transaction timeout value is too low can also generate a Failed on Start, specially when a lot of task (several hundreds) are created by the workflow which try to store the in a SQL Server transaction. the information you will find in the Sharepoint log file is soething like this

Workflow Infrastructure             72fg     High    Error in persisting workflow: System.Transactions.TransactionAbortedException: The transaction has aborted. ---> System.TimeoutException: Transaction Timeout     --- End of inner exception stack trace ---     at System.Transactions.TransactionStateAborted.CreateAbortingClone(InternalTransaction tx).

One possible workaround is to increase the timeout value in the web.config file.  By default the value is set to 1 minute.  You can increase the value to 5 minutes for instance :

<configuration>

  <system.transactions>

    <defaultSettings timeout="00:05:00"/>

  </system.transactions>

</configuration>

4.repair of the .NET 3.0/.Net 3.5 Framework may be necessary. If you have SP1 for the .NET Framework installed, just go into the Control Panel/Add Remove Programs and click the Change button on Microsoft .NET Framework 3.0 SP1. If you don't have the Service Pack you can install it. The Change process takes about 2 minutes.

5.A more exotic one : Workflow Foundation performance counters not loaded

Reload them again:  Lodctr "c:\Windows\Microsoft.Net\Framework\v3.0\Windows Workflow Foundation\perfcounters.ini"

Introduction

A very good practice in software is to work with roles instead of working with individuals.

I’ve  often noticed in the Sharepoint newsgroups that assigning a workflow task to a group seems to be a popular question.

First off you cannot assign a Task to Active Directory groups, but only to  Sharepoint groups !

Hands-on

• Let start by using the HelloWorldSequential workflow sample provided with the Sharepoint sdk. Open up the project in Visual Studio 2008 and modify the Install.bat file to specify your site collection url (for the feature activation) : find  the http://localhost string and replace it with your site collection url.
• Double click on Workflow1.cs to display the workflow in the Visual Studio workflow Designer.
• Double click on the createTask1 activity to get into the code editor.

• In the associated code (the CreateTask function), replace the line taskProps.Assignee with code described in the red rectangle below.We assume our approvers must be part of a (custom) group called “MyApproverGroup” that we will create later.

• Create a new group, name it MyApproverGroup, add several users; give this group the Contribute permission.

• Rebuild your solution, and start Install.bat; make sure the feature is activated in the site collection features, create a custom list, associate the workflow with the list and start an instance of the workflow and check the task list : indeed, a task has been created by the workflow and assigned to the MyApproverGroup.

• Login as one of the group user :

• Go to the task list and change the view to “By My Groups”, the new task shows up :

Congratulations !

I just registered for the Sharepoint Conference (Las Vegas) that will be the conference to learn about SharePoint 2010.

Join the newly created Facebook Events page for the SPC09

Just taking a loan in the house before heading to the casino…