I’ve a custom NativeActivity with a bunch of InArguments. It will always be the root activity when the client is editing it’s workflow on a rehosted designer. So far so good.
The problem is, although InArguments are showed on PropertyInspector, no ‘Arguments’ tab is showed. I understand why it happens but I really want to make this NativeActivity to be the root activity for a variety of reasons: I can customize it on my way, I can give it a custom Designer, etc.
How can I had argument properties to a NativeActivity in a way that they’re showed on ‘Arguments’ tab within the designer making them available and allowing the client to do whatever he/she wants with the InArguments without the “‘argumentName’ is not declared. It may be inaccessible due to its protection level” think?
What I’ve tried:
- Just like variables, where we can use a Collection{Variable} and the designer recognizes it as the place where the activity variables are, I’ve tried Collection{Argument}. No luck!
- Simply write InArgument within NativeActivity. They’re showed on Property Inspector but can’t be used within the workflow through the designer. Again they cannot be resolved and”‘argumentName’ is not declared. It may be inaccessible due to its protection level” happens.
- Bind previous InArguments to RuntimeArguments through CacheMetadata() using metadata.AddArgument() and metadata.Bind(). No luck whatsoever.
I known that ActivityBuilder is probably the best way to solve this. I successfully tried something like:
ActivityBuilder builder = new ActivityBuilder();
builder.Implementation = new MyCustomNativeActivity();
DynamicActivityProperty property = new DynamicActivityProperty()
{
Name = "TestArg",
Type = typeof(InArgument<string>),
};
builder.Properties.Add(property);
Designer.Load(builder);
But this leads to bad code because I’ve to had the arguments when I’m loading the designer. This prevents me from having a library with my custom activities separated from the forms code itself. Mainly because ActivityBuilder is a sealed class, much like DynamicActivity which, I assume, would work too.
Is there any way to simulate the ActivityBuilder behaviour, that allow to add properties at codetime, but using a NativeActivity which can be easily inherited and customized?
I hope I’ve made myself clear.
P.S.: I also took a look at IExecutionProperty but I didn’t understand well how it works, what’s its purpose and if it can be applied here.
Thanks
It seems that my problem is known and there’s no plan to support it on next WF releases.
Links with explanations and a few workarounds: here and here.