Code in the constructor is an anti-pattern that gets you in trouble as it just did. All a constructor should do is initialize the private fields and make sure the object is in a valid state. Initializing properties and calling methods should be done from other methods. Avoid getting/setting properties in the constructor. Getting or setting a property is an innocent looking method call, the setter/getter of the property. The setter/getter can do any number of things that will fail if the object isn't fully constructed yet, which is the case if the setter is called from within a constructor, and what happened in your case.

 

The safe way to create and initialize an Entity is by means of a factory method. Following is a simple example.

 

    public class StaffingResource : AuditEntityBase
    {
        internal StaffingResource()
        {
        }

        public static StaffingResource Create()
        {
            return new StaffingResource { Id = CombGuid.NewGuid() };
        }
    }

Hi Greg,

I added the 2 items (PropertyInterceptor and RelatedEntityList) above to my design time data sample solution and didn't encounter any issue. 

In the PropertyInterceptor case, I have both AfterSet and AfterGet, and I can see the AfterGet being applied and invoked.

Same thing with the RelatedEntityList. I have Customer and Orders and I can see my Orders mock data on the data grid.

One suggestion is to debug your design time data invocation when you bring your XAML up in the designer mode. You can do this by bringing up another copy of your solution and attach this solution to the other using Debug - Attach to Process. You can then put breakpoints and see what's going on.

I've attached my sample solution here. I'm using DevForce 6.1.8.1 and SL4.

If you're using SL5, please note that we have encountered known issues with design time data when SL5 is installed. Here's a couple of links that have more info.

Please let me know if I'm missing anything.