Windows Workflow: Debugging Limitations.

In Visual Studio Debugger for Windows Workflow Foundation you MUST set the workflow DLL project as the Visual Studio solution startup project to debug the workflow using F5
Documented in
It is not intuitive restriction.
I’ve posted to MS Feedback that it will be good to support workflow Debugging from any startup project.

Recently I’ve noticed, that if workflow DLL project is a startup project, it doesn’t support Edit&Continue in a code dlls. Another thing that MS should improve. It’s similar to ASP.Net Web Site limitation of Edit&Continue.

I also not able to open activity from call-stack- see my post Windows Workflow: Concatenate all parents QualifiedNames- instead of call stack

ASP.NET Conversion to WAP bug – autoeventwireup Changed to True

When ASP.NET page converted to WAP, it changed autoeventwireup to True- see autoeventwireup Changed to True in C# Conversion to WAP  discussion.

Autoeventwireup is easier for coding, but there are  disadvantages(according to MSDN):

One disadvantage of the AutoEventWireup attribute is that it requires that the page event handlers have specific, predictable names. This limits your flexibility in how you name event handlers. Another disadvantage is that performance is adversely affected, because ASP.NET searches for methods at run-time. For a Web site with high traffic volumes, the impact on performance could be significant.

After conversion you should check the code for consistency:

 If autoeventwireup=”true”, ensure that event wiring from the code behind pages has been removed as well.

If you include explicit binding for page events, be sure that the AutoEventWireup property is set to false so that the method is not called twice.

MSDN recommends that you always set AutoEventWireup to FALSE while working in Visual Studio .NET (from article it is not obvious, is recommendation applicable for VS 2008).
More explanations why AutoEventWireup  should be set to false:
K Scott Allen’s “Inside AutoEventWireup” blog and

However ScottGu comment in :
From a performance measurement perspective, there is no difference between autoeventwireup=true/false.

TryXmlSerialize function

I was using XmlSerialize method from a while.

Recently I found that sometimes it's safer to use TryXmlSerialize:

    /// <summary>
    /// Serialize an object into XML
    /// </summary>
    /// <param name="serializableObject">Object that can be serialized</param>
    /// <returns>Serial XML representation</returns>
    public static bool TryXmlSerialize(object objectToSerialize, out string strXml)
        bool bRet=true;
          strXml =XmlSerialize( objectToSerialize);
        catch (Exception exc)
        return bRet;
I've also found useful to specify inside XmlSerialize
writer.Formatting = Formatting.Indented;

Windows Workflow: Use of ConditionedActivityGroup activity

One of our developers used ConditionedActivityGroup activity with a single branch.
ConditionedActivityGroup is a kind do of loop, but it should not be used instead of the WhileActivity.
There are a few reasons for this:
1.Use the simplest tool that satisfy your requirement
2.workflow designer doesn’t expand body of ConditionedActivityGroup, and you need to click it to Preview
3. If you have many activities in the workflow, the designer becomes terribly slow(VS 2008)
The huge workflows should be considered for refactoring by converting parts of workflow into custom composite activity or as separate worklow (with InvokeWorkflow activity)
I have a question,  should I use Code Conditions vs Rule Conditions?
The article Windows Workflow: Rules and Conditions describes these types of conditions.
Conditional Activities in Windows Workflow Foundation talks about Advantages of using Rule Conditions:


  • Rule conditions are included in the declarative model and can be dynamically updated at run-time
  • The .rules file provides code separation and enables external analysis /tools to be built on top of the .rules file.  
Also to set the conditions declaravely via Rules  simpler for new Activity.
However if you are using code-behind for the workflow, specify code conditions is more consistent and easy to maintain/investigate.
Editing declarative conditions in Workflow Designer is too slow.
Also VS “find references”  could NOT see the references from rule conditions, which make development harder.

Remoting asyncronous call to fire and forget

I want to do .Net Remoting asyncronous call with “fire and forget” approach.
MSDN statement in OneWayAttribute Class documentation is not clear “The method can execute synchronously or asynchronously with respect to the caller.”  
Thanks to manish godse’s blog : OneWay messages in remoting post: invoking a method with [OneWay] attribute the client will not wait for a response and the call will return immediately. In essence the call gets converted to an async call and the client doesnt wait for a server response. The async behaviour for [OneWay] messages is true, when you are invoking a method on a remoting proxy. Invoking the same method on a regular object will be called synchronously like any other method.
Similar explanation is in Using OneWayAttribute for Remote Calls article.
In a summury, to call a Remoting method asyncronously to “fire and forget”, you need to mark a method on your remote INTERFACE with OneWayAttribute.
Related links: