Question

In my project I have two libraries that would currently result in a circular dependency which I am unable to resolve.

One library provides common data structures for the whole solution. This library contains a construct similar to this:

namespace Common {
  public class Foo {
    //[Editor( typeof( UserEditor ), typeof( UITypeEditor ) )]
    public UInt32 OwnerId { get; set; }
  }

  public class User {
    public UInt32 Id { get; set; }
  }
}

Now in one of the projects in our solution, we would like to edit Foo instances through a PropertyGrid and the OwnerId property should be edited with a custom editor; this one:

using Common;

namespace Common.Gui {
  public class OwnerEditor : UITypeEditor {
    public static List<User> Users { get; set; }
  }
}

Now, I can’t just add an EditorAttribute to Foo.OwnerId because that would create a circular dependency and I would like to keep references to Common.Gui out of Common anyway. I would also like to avoid pulling code out of Common into a new assembly as a lot of other projects reference it.

I found a question regarding adding EditorAttribute at runtime, which sounded like a perfect solution, but I was unable to adept that to my problem.

Answer 1

I think that this is a sign of a flawed design. Do you want the class library containing Foo to be unknowning of the editing GUI? In that case it shouldn’t contain the EditorAttribute.

One solution could be to regard the Foo class as your model in a MVVM architecture. Then you can create a wrapping ViewModel in the GUI class library where the EditorAttribute is applied. If you extract an interface IFoo which i placed in your model class library you can use the decorator pattern.