erikj

Hi,

I'm on Beta 1 of Orcas and ave a question about inheriting from a base workflow. My base sequential workflow type has a simple set of fault/cancel/completion handlers. I then create a new sequential workflow project, add a reference to my base workflow's assembly, and then on the new workflow change the "Base Class" property to my base workflow type. Instantly, the new workflow fails to show up in the designer with an error "Duplicate Component name 'BaseFlow.FaultHandler1'. Component names must be unique."

It looks like the designer is grabbing components from the base workflow and adding them into the derived workflow class. If I remove them by hand from the derived workflow type, it compiles and works as intended. So, my question is whether I am simply doing this wrong and there is another way to declare handlers in a base workflow type or if this is just a problem with the Orcas beta 1 bits. Anyone know Thanks,

-Erik




Re: Windows Workflow Foundation Inheriting from a Base Workflow (Orcas B1)

Tom Lake - MSFT

Can you post the code you are using for you base workflow




Re: Windows Workflow Foundation Inheriting from a Base Workflow (Orcas B1)

erikj

Tom,

The code is below and here are the steps to reproduce. It turns out I was probably on the wrong tack anyway. I wanted to implement fault and cancel handlers in the base workflow that signals my framework. But I think you are only allowed to have one fault handler catch a specific fault type per workflow type -- so I'm not sure if trying to do this in a base workflow would have worked as planned.

To reproduce, create a sequential workflow library project. VS will create a new workflow type for you (I renamed mine to "BaseFlow" to help keep things straight). Add a code activity to the cancel handler -- mine just writes a note to the console. Removed the "sealed" keyword from the workflow class declaration. Compile the project.

In the same solution, create a new sequential workflow console application project. You have to create a separate project because the workflow designer will not let you assign a workflow a base type that is defined in the same project as the derived workflow (not sure why that matters). Add a reference to the base workflow project. Then, open the workflow designer for the newly created workflow type in the console app project (it will probably already be open). Go to the workflow properties and click the property editor button ("...") in the Base Type property. This opens the type chooser and you should be able to find the "BaseFlow" workflow type. Choose it and close the type chooser. On my system, the workflow designer immediately shows the error. If you look at the code for the derived workflow, you can see that the designer has recreated the cancel handler components found in the base class, which breaks the compiler.

Here is the code for my base workflow type -- hope this helps!

BaseFlow.cs:

namespace BaseFlowLibrary

{

public partial class BaseFlow: SequentialWorkflowActivity

{

public BaseFlow()

{

InitializeComponent();

}

private void CancelCode_ExecuteCode(object sender, EventArgs e)

{

Console.Out.WriteLine("Workflow is cancelled!");

}

}

}

BaseFlow.designer.cs:

namespace BaseFlowLibrary

{

partial class BaseFlow

{

#region Designer generated code

/// <summary>

/// Required method for Designer support - do not modify

/// the contents of this method with the code editor.

/// </summary>

[System.Diagnostics.DebuggerNonUserCode]

private void InitializeComponent()

{

this.CanModifyActivities = true;

this.CancelCode = new System.Workflow.Activities.CodeActivity();

this.CancelHanders = new System.Workflow.ComponentModel.CancellationHandlerActivity();

//

// CancelCode

//

this.CancelCode.Name = "CancelCode";

this.CancelCode.ExecuteCode += new System.EventHandler(this.CancelCode_ExecuteCode);

//

// CancelHanders

//

this.CancelHanders.Activities.Add(this.CancelCode);

this.CancelHanders.Name = "CancelHanders";

//

// BaseFlow

//

this.Activities.Add(this.CancelHanders);

this.Name = "BaseFlow";

this.CanModifyActivities = false;

}

#endregion

private CodeActivity CancelCode;

private CancellationHandlerActivity CancelHanders;

}

}

Workflow.cs (after the base type property is changed):

namespace TestApp

{

public sealed partial class Workflow1 : BaseFlowLibrary.BaseFlow

{

public Workflow1()

{

InitializeComponent();

}

}

}

Workflow1.design.cs (after the base type is changed and the project is broken):

namespace TestApp

{

partial class Workflow1

{

#region Designer generated code

/// <summary>

/// Required method for Designer support - do not modify

/// the contents of this method with the code editor.

/// </summary>

[System.Diagnostics.DebuggerNonUserCode]

private void InitializeComponent()

{

this.CanModifyActivities = true;

this.CancelHanders = new System.Workflow.ComponentModel.CancellationHandlerActivity();

this.CancelCode = new System.Workflow.Activities.CodeActivity();

//

// Workflow1

//

//

// CancelHanders

//

//

// CancelCode

//

this.CancelCode.Name = "CancelCode";

this.CancelCode.ExecuteCode += new System.EventHandler(this.CancelCode_ExecuteCode);

this.CancelHanders.Activities.Add(this.CancelCode);

this.CancelHanders.Name = "CancelHanders";

this.Activities.Add(this.CancelHanders);

this.Name = "Workflow1";

this.CanModifyActivities = false;

}

#endregion

private CancellationHandlerActivity CancelHanders;

private CodeActivity CancelCode;

}

}






Re: Windows Workflow Foundation Inheriting from a Base Workflow (Orcas B1)

Tom Lake - MSFT

I should have read your initial post one more time before asking for the code, as I just did. This is a known V1 limitation and is not supported in the designer. The is partly because of the problem you are seeing, having all the children from the base activity duplicated in the derived activity. The work around you have suggested should work, but any time you make a change to the workflow that causes it to be serialized will bring the duplicate activities back. One resolution for this if you don't mind not having the designer is to just use normal class library project for this derived activity. Keep in mind that the activity validators won't be called during compilation, since it is not in a workflow project, but they will be called when the derived activity is used in a workflow. Take a look at the post at http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=670060&SiteID=1 for a little more info.




Re: Windows Workflow Foundation Inheriting from a Base Workflow (Orcas B1)

erikj

Thanks for the explanation, Tom. I think I'll use a different approach to deal with my requirements.