CSLA 3.6 : One or More properties are not registered for this type

CSLA 3.6 : One or More properties are not registered for this type

Old forum URL: forums.lhotka.net/forums/t/11934.aspx


Aravinda posted on Friday, April 12, 2013

Hi,

 We have some of our applications running wih CSLA 3.6 framework. Now and then system throws this following error:

One or More properties are not registered for this type.

This error is not conistent and appears once over a period of several months. The class representing this type is derived (inherits) from another class which inherts BusinessBase.  All properties are defined in base class. 

 I  read somewhere that inheritance among user defined defined is not encouraged in CSLA framework.

 How do we consistently reproduce this error? And how to fix it?

Thanks in advance,

-Aravinda

skagen00 replied on Friday, April 12, 2013

Are your intermediate base classes concrete or abstract?

I think inheritance is very valuable in terms of providing behavior... after all, that's what we're doing from CSLA's base classes.

If your intermediate class is concrete, you'll generally have problems (I've found).  If it's abstract you should be good.

JonnyBee replied on Saturday, April 13, 2013

What type of application is this? 

If it is a web app it might be a treading related issue when AppPool is recycled. 

Aravinda replied on Tuesday, April 23, 2013

Jonny,

  It is web app. Could this problem be caused because the base class and derived classes are in two different threads?

Aravinda replied on Tuesday, April 23, 2013

Hi,

  The intermediate base classes are concrete classes. If I create an abtract class and use that as source of inheritance in derived class, will it solve the problem?

skagen00 replied on Tuesday, April 23, 2013

All classes except the final one, I believe, need to be abstract.  (At least that is my experience).

I'm guessing your reluctance to making your base classes abstract is that you use them for polymorphic behavior.

If that's correct, what I would suggest is -

* make your base class abstract AND generic (I'm assuming maybe it's not?)

* create an interface to represent the public members of your base class, have your abstract base class implement it

* where using polymorphic behavior, have a reference of the interface rather than the previously concrete base class

If not, is there another reason why you can't just make your base classes abstract?

 

Copyright (c) Marimer LLC