locked
problem executing NativeActivity RRS feed

  • Question

  • My workflow contains this activity:

    [

    Designer(typeof(DesignerLibrary.ActivityDesigner1))]

     

    public sealed class InvokeCreateVolume : NativeActivity<IVolume>

    {

     

    public InArgument<int> WorkflowId { get; set; }

     

    public Activity Body { get; set; }

    [

    RequiredArgument]

     

    public InArgument<uint> SizeInGB { get; set; }

    [

    RequiredArgument]

     

    public InArgument<IStorageSource> StorageSource { get; set; }

     

    protected override void CacheMetadata(NativeActivityMetadata metadata)

    {

     

    var workflowIdArgument = new RuntimeArgument("WorkflowId", typeof(int), ArgumentDirection.In);

    metadata.Bind(WorkflowId, workflowIdArgument);

    metadata.AddArgument(workflowIdArgument);

    metadata.AddChild(Body);

    }

     

     

    protected override void Execute(NativeActivityContext context)

    {

    Body =

    new InvokeMethod
     

    {

    DisplayName =

    "SuperCreateVolume",

    TargetObject = StorageSource,

    MethodName =

    "CreateVolume",

    Parameters = {SizeInGB}

    };

    context.ScheduleActivity(Body);

    }

    }

    

    When I try to run the workflow the line context.ScheduleActivity fails with the error:

    

    

    The provided activity was not part of this workflow definition when its metadata was being processed.  The problematic activity named 'SuperCreateVolume' was provided by the activity named 'InvokeCreateVolume'.

    Parameter name: activity

    Does anybody Know how to fix it? note the arguments SizeInGB and StorageSource which I need that come from my custom designer.

    

    Thanks!

    Thursday, October 20, 2011 12:28 AM

Answers

  • Hi Ale,

     

    Please check this one.

    http://stackoverflow.com/questions/2374911/scheduling-runtime-specified-activity-in-workflow-4-rc

    Workflow 4.0 only allows you to schedule children which were part of the tree before you started execution.

    This rule probably exists because the tree so built is re-usable by multiple worklfow instances. If instance A were to modify the tree while instance B is still running, the results would give the runtime team horrible headaches.

    In practice this means the only way you can do what you want with scheduling the child dynamically at runtime is to kick off an entirely new workflow (and optionally wait for that to complete).

     

    Regards, 


    MB
    • Marked as answer by LeoTang Sunday, October 30, 2011 1:22 PM
    Thursday, October 20, 2011 8:32 AM