locked
Issue registering a custom designer for a WF 4 Activity RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    I'm working on a custom activity for WF 4, but I can't seem to get my designer registered the way I want it to be registered.
    The documentation specifiies two ways to register a designer for a workflow activity.

    1. Use the [Designer] attribute on the activity. This requires a dependency on the designer library from the activity library.
    2. Use a Metadata class in the designer library that implements IRegisterMetadata. This swaps the dependency around.

    I want to use the last option, but Visual doesn't seem to want to load the designer when I follow the guide in the documentation. When I use the Designer attribute it works fine, but then I need to have a dependency on the designer library or use a string-identifier of my designer class. Which isn't really maintainable either.

    How can I get option two to work for my custom activity?

    • Edited by Willem MeintsMVP Saturday, November 28, 2009 3:46 PM Layout issues with the post
    • Moved by Andrew_Zhu Wednesday, December 2, 2009 7:40 AM (From:Windows Workflow Foundation)
    Saturday, November 28, 2009 3:45 PM

Answers

  • Question
    Sign in to vote
    1
    Sign in to vote
    [Note: the answer depends on whether you are in VS or you are rehosting. In a rehosted app, you can call IRegisterMetadata.Register any way you like, or define your own metadata loading scheme. In VS there is a metadata loading scheme which implements 'Option 2'.]

    Option 2 is the way to go, but how does VS find the DLL?
    IRegisterMetadata classes are invoked only when certain conditions are met:

    If your activity dll is called Foo.dll, your design dll must be called Foo.Design.dll.

    2) Your Design dll must be in one of the search paths WF Designer looks at:

    For non-gac'd assemblies:
    The search path that should definitely work for Beta2 is the very same directory which Foo.dll is located in.

    While you are developing things in VS note that the assembly Foo.dll may be being loaded from either bin\debug\Foo.dll or obj\debug\Foo.dll, depending on which project you are looking at. Working around this by using the same intermediate output path is a possibility.

    Finally, trouble-shooping steps to check if/how your registration process is going wrong. You can see whether VS tried to load your Metadata assembly or not by noticing which DLLshave been loaded into the process. If your DLL is loaded in the process but metadata still isn't working, you might also try debugging VS and breaking on all Exceptions, in case your registration code is throwing.
    Wednesday, December 2, 2009 6:48 PM