The Designer
attribute (using "magic" string) is not something very reliable. If you change your class name or namespace, you'll not have a compilation error.
There is another (better imho) way to do it using IRegisterMetadata
implementation:
- Your Design assembly must reference your activity assembly, but this usually can't be avoided.
- Add a partial class (.cs) to your XAML designer
- This class must inherit from
System.Activities.Presentation.Metadata.IRegisterMetadata
. this interface only define one method to implement.
Here is a implementation sample:
public void Register()
{
AttributeTableBuilder builder = new AttributeTableBuilder();
builder.AddCustomAttributes(
typeof(MyActivity),
new DesignerAttribute(typeof(MyActivityDesigner)));
MetadataStore.AddAttributeTable(builder.CreateTable());
}
Next, you'll want to have the custom designer used in Visual Studio. Visual Studio have strict rules to automatically load designer assemblies. You need:
- Your designer project must have the same name than your activity project, with ".Design" added at the end. Example:
- Activiy project: MyApp.Activities.dll
- Designer project: MyApp.Activities.Design.dll
- The .Design dll must be in the same directory than the activity dll. You can automate this with a post build event in the designer project.
Important Edit:
I see now that your links already present this method but you say that it directly reference the DLL. Yes, the DESIGN dll reference the ACTIVITY dll.
But you asked the opposite: the activity dll shouldn't reference the design dll.
Using the IRegisterMetadata method, your DESIGN dll can reference the ACTIVITY dll, it's not a problem: you can remove the design dll from the released package, the activity dll will work fine.