1

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.

Community
  • 1
  • 1
Oliver Salzburg
  • 21,652
  • 20
  • 93
  • 138

2 Answers2

2

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.

Anders Abel
  • 67,989
  • 17
  • 150
  • 217
2

You can reference the editor class by name to create a runtime reference.

public class Foo {
    [Editor( "Common.Gui.OwnerEditor, Common", typeof( UITypeEditor ) )]
    public UInt32 OwnerId { get; set; }
  }
Tim Rogers
  • 21,297
  • 6
  • 52
  • 68
  • However, I do agree with Anders' answer. Your Common module still knows about your GUI module, so it's not a great design. – Tim Rogers Jun 01 '11 at 10:42
  • +1: You can see this all over the MS libraries referring to the *.Design.dll 's. – leppie Jun 01 '11 at 10:42
  • In fact, I tried that to resolve the dependency initially, but it caused the editor to not be used in the PropertyGrid. Edit: My mistake, that was caused by a typo. This suggestion works fine now. – Oliver Salzburg Jun 01 '11 at 10:50