CSLA .NET 3.5 Beta 1 available

It’s great!

Can I build it with .Net 2.0?

Thanks

I have made CSLA .NET version 3.5 Beta 1 online for download at www.lhotka.net/cslanet/download.aspx. Both VB and C# versions are available.

Please read the change log to get an idea of all the changes, and check out the various 3.5 related threads here on the forum as well.

At this point version 3.5 is feature complete - I'm not adding anything new.

There are probably some bugs, and any help you can provide in finding them and letting me know about them is VERY appreciated!!

Barring anyone finding some major hole in my implementation, the only changes going forward should be bug fixes and stability and performance enhancments. The public API for mainstream business object creation should be stable going forward. Advanced extensibility APIs may still be subject to change, though I hope not.

(For those working with the 3.5 preview releases, there's one big change you should know about up front. The property declaration syntax now requires you to use a RegisterProperty() method. Check the change log and/or ProjectTracker.Library to see the new syntax. I apologize for making such a change right before beta, but the 30%+ performance increase was too important...)

CSLA .NET is for .NET 3.5 only. I’m using new language features that are only in the 3.5 C#/VB compilers.

CSLA .NET 3.0.x is the .NET 2.0/3.0 version of CSLA and will remain so until it all fades away into the past. I’ll release 3.0.4 (bug fixes) when I release 3.5, and will create other point releases if needed for bug fixing, but the future is .NET 3.5.

Rocky

It’s great!

Can I build it with .Net 2.0?

Thanks

I have made CSLA .NET version 3.5 Beta 1 online for download at www.lhotka.net/cslanet/download.aspx. Both VB and C# versions are available.

Please read the change log to get an idea of all the changes, and check out the various 3.5 related threads here on the forum as well.

At this point version 3.5 is feature complete - I'm not adding anything new.

There are probably some bugs, and any help you can provide in finding them and letting me know about them is VERY appreciated!!

Barring anyone finding some major hole in my implementation, the only changes going forward should be bug fixes and stability and performance enhancments. The public API for mainstream business object creation should be stable going forward. Advanced extensibility APIs may still be subject to change, though I hope not.

(For those working with the 3.5 preview releases, there's one big change you should know about up front. The property declaration syntax now requires you to use a RegisterProperty() method. Check the change log and/or ProjectTracker.Library to see the new syntax. I apologize for making such a change right before beta, but the 30%+ performance increase was too important...)

I was not keen on making such a big change like that, but the performance benefits are remarkable. There’s a very real cost to using this managed field concept, and performance tuning is important – especially a straight-up 30% improvement!

I could see where properties in abstract classes could be problematic. You probably need to register them in the subclass, even though the implementation is in the base class. Interesting problem…

Rocky

Kind of a big change in there with the RegisterProperty at the last moment!

After having made the changes to my objects, I'm getting an interesting behavior.

For instance, with one property, it'll crash reliably upon trying to load it.

LoadProperty<string>(_sortName, sdr.GetString(_sortName.DataColumnName));

+  $exception {"Property load or set failed for property SortName (Unable to cast object of type 'System.Int32' to type 'System.String'.)"} System.Exception {Csla.PropertyLoadException}

But then, after re-trying the request, it breezes through it and works fine. But then gets caught up with another problem:

DataPortal.Fetch failed (Property load or set failed for property SystemId (Index was outside the bounds of the array.))

It's possible I may be running into some problems with a concern I had once I saw this change with respect to inheritance and properties that exist in generic abstract classes, but I'll know more once I look into it further. With the preview release, I was working fine with the properties. (We happen to use a derivative of PropertyInfo but it's really nothing).

I’m open to suggestions J

The challenge of course, is that the list of properties for a type is stored in a dictionary keyed by that type. Each PropertyInfo object has an Index property that is set to a specific array location.

So actually registering in the subclass won’t necessarily help either, as reuse of a PropertyInfo isn’t possible. If a PropertyInfo was used in 2+ types the Index property would only be valid for one of them and would mess things up in the other(s).

There’s no guarantee of the order in which static initialization occurs either. In other words, the base class could be initialized after the subclass, so I can’t necessarily just grab the list of PropertyInfo objects from the base class type, because they might not yet be in the dictionary.

Rocky

Rocky: I could see where properties in abstract classes could be problematic. You probably need to register them in the subclass, even though the implementation is in the base class. Interesting problem…

That seems to me to be a bit of a problem... hopefully there's a way around this.

I think I have a solution – conceptually anyway.

Though you can’t guarantee the order in which static initialization will occur, there’s no doubt that by the time the first instance method is called all static initialization has taken place.

So what I can do is passively accumulate the PropertyInfo objects into Type-indexed lists.

Then, when the first attempt is made to get/set a property I can walk up the inheritance hierarchy and ensure the Index properties of all PropertyInfo objects are set, with the top-level base class’s properties starting at 0 and counting up, then the next subclass, and the next, all the way out to yours.

What a cool algorithm!

Rocky

Rocky: I could see where properties in abstract classes could be problematic. You probably need to register them in the subclass, even though the implementation is in the base class. Interesting problem…

That seems to me to be a bit of a problem... hopefully there's a way around this.

This is the reason for beta releases – I really appreciate your feedback and help getting it all working!!

I’ll let you know when there’s something to test. You might find it easiest to download TortoiseSVN and just grab the files directly from my repository

http://www.lhotka.net/cslanet/Repository.aspx

Rocky

I'm very interested to see how this might work!

I have three classes in the hierarchy I'm working with.

1) Entity<T>, which includes an Id and timestamp information for user creation and modification

2) ProfileName<T>, which encompasses organization and individual names.

3) IndividualName (which includes things such as first name, etc.)

What was interesting is that I was getting the registerproperty calls firing for #1 and #3, but the mFieldData was getting initialized then (excluding the two properties for #2) and then the register property calls for #2 would fire. Obviously this would explain why subsequent requests would work - the mFieldData got initialized properly with the entire list.

I really appreciate you taking this issue into consideration so quickly. If you have a solution you'd like me to try within my code, just tell me which files to grab from your source and I'll verify it solves the problem I was encountering. I'll watch this thread or my e-mail is chlusak@microedge.com.

Whenever you find the time, of course. As always, thanks!

Chris

Maybe I should be clear about what I made it support.

You can have a base class. The base class defines properties and registers them all by itself. Those properties are registered against the base class type of course:

public class Base<T> : BusinessBase<T> where T: Base<T>

{

  private static PropertyInfo<string> NameProperty = RegisterProperty<string>(typeof(Base<T>), new PropertyInfo<string>(“Name”));

  // …

}

The subclass registers its properties against its own type:

public class EndClass : Base<EndClass>

{

  private static PropertyInfo<string> TitleProperty = RegisterProperty<string>(typeof(EndClass), new PropertyInfo<string>(“Title”));

  // …

}

Then you use these:

EndClass x = new EndClass();

x.Name = “fred”;

x.Title = “CEO”;

Rocky

Unfortunately there appear to still be issues (at least for me). It's hard to debug but I'm working through trying to understand it all. Hope to be able to provide more feedback for you soon.

I very much doubt the issue is actually with the order of properties being wrong within a specific type, because you’ll note that the propertyinfo objects are sorted within a type. It doesn’t matter in what order the propertyinfo fields are initialized, they end up in the same order regardless. Unless I missed something of course J

I don’t trust that MSDN article’s assertion. I know for a fact that C# and VB act differently in how fields/properties are managed in some cases – VB sorts and C# does them in order (or maybe it was the other way around). Don’t ask me why, and I don’t know that this difference includes static fields – but order-of-initialization seems like a risky assumption to make in any case.

Hence the sorting, so there’s a guaranteed order.

My guess is that it is a different problem – specifically the one I was fighting with the auth code, where you can’t predict the order in which the types in your inheritance hierarchy will initialize. In fact, it is quite possible for an intermediate type (one in the middle of the hierarchy) to not initialize until very late in the process – after both the business subclass and Csla.Core.BusinessBase have initialized. There appears to be no direct solution to this problem that can be implemented purely within CSLA – the issue is too low-level within .NET.

The solution I’ve come up with to the problem is somewhat of a hack, and involves setting the value of a static field from within the constructor (which solves the auth issue).

Of course deserialization doesn’t run constructors, so I’m guessing this static field must be set within OnDeserialized() as well. That may be true for the auth case as well (probably is now that I think about it).

If my theory is right, you can add code like this to your class:

[Serializable]

public abstract class BusinessBaseX : …

{

  private static int _dummy;

  private BusinessBaseX()

  {

    _dummy = 42;

  }

  protected override void OnDeserialized()

  {

    _dummy = 42;

  }

}

That’ll force the initialization of the static fields in this intermediate class during the deserialization process, forcing the propertyinfo field(s) to be initialized on the app server during deserialization.

The trick is that _dummy must be declared in each specific intermediate class, because static fields are initialized on a per-type basis. There’s no way (short of maybe some reflection hacks – and even that would require extra code in each intermediate class) for Csla.BusinessBase to ensure that all static fields are initialized in the inheritance hierarchy. But this should do the trick.

Rocky

Oh you can bet this’ll get discussed in the book J

Rocky

Sure enough, having a _dummy static variable in the intermediate class took care of it.  I had a dummy var in my most base class (which didn't have any PropertyInfo objects) and in my business object classes.  I figured it was some .NET Framework quirk, like you said.

You may want to put this into your documentation because, per my understanding, it's still considered a CSLA best practice to have our own intermediate classes from which we inherit, rather than inheriting directly from BusinessBase.

No, this helps a lot.

It appears there are some odd things with static initialization where it is possible for instance code to run before static fields have been initialized. This flies in the face of my understanding, so I need to do some research on this to see whether it is a .NET 3.5 compiler change or something…

But I can walk through the debugger and watch instance code running before the static field initializers – in the same type!! Unreal!

So you are right, it is a timing issue.

One solution appears to be to put the RegisterProperty() calls into a static constructor, because that still runs before any instance code within a type. But that’s a pretty lame solution imo…

Rocky

I know this is of very little help thus far but I'm still having perhaps some sort of a timing issue.

When GetConsolidatedList is getting run, it happens after 13 of 15 properties for IndividualName have been registered. 8 for the IndividualName class, 5 for Entity<T>, but not the 2 for ProfileName<T>. So, it ends up with an incomplete list.

Entity<T>(5)----ProfileName<T>(2)----IndividualName(8)

Why the five fire for Entity<T> but not the two for ProfileName<T>, you got me. I certainly haven't abandoned this and I'll give you whatever useful feedback I can.

Wow!

http://msdn2.microsoft.com/en-us/library/aa645758(VS.71).aspx

It turns out that static initializers are only guaranteed to run before the first use of a static field. Instance code can run all it wants before the static fields are initialized.

Another solution is to include an empty static constructor in your base class. At least you don’t need to move the RegisterProperty() calls there – just having an empty static ctor is enough for force the behavior we need.

But implementing a static ctor forces the compiler to inject a bunch of code around your class, which can be a perf issue (or so I’ve read). So it is best to avoid static ctors if possible.

So here’s a solution I just tested that seems to work (though it is clearly a hack). If the rule is that a static field must be used, and we know that the instance ctors all run up the inheritance hierarchy, you can have your instance ctors “touch” a static field in each base class:

public class Base<T> …

{

  private static int _dummy;

  protected Base()

  {

    _dummy = 0;

  }

}

As the instance ctors run in each class in your inheritance hierarchy, you are guaranteed that this dummy field is set. That forces initialization of all static fields in the class, thus ensuring that all the base classes have initialized their static fields by the time your subclass’s ctor runs, and thus before any chance of trying to get at the consolidated list of registered properties.

Rocky

No, this helps a lot.

It appears there are some odd things with static initialization where it is possible for instance code to run before static fields have been initialized. This flies in the face of my understanding, so I need to do some research on this to see whether it is a .NET 3.5 compiler change or something…

But I can walk through the debugger and watch instance code running before the static field initializers – in the same type!! Unreal!

So you are right, it is a timing issue.

One solution appears to be to put the RegisterProperty() calls into a static constructor, because that still runs before any instance code within a type. But that’s a pretty lame solution imo…

Rocky

I know this is of very little help thus far but I'm still having perhaps some sort of a timing issue.

When GetConsolidatedList is getting run, it happens after 13 of 15 properties for IndividualName have been registered. 8 for the IndividualName class, 5 for Entity<T>, but not the 2 for ProfileName<T>. So, it ends up with an incomplete list.

Entity<T>(5)----ProfileName<T>(2)----IndividualName(8)

Why the five fire for Entity<T> but not the two for ProfileName<T>, you got me. I certainly haven't abandoned this and I'll give you whatever useful feedback I can.

I’m not sure I can shed a lot of light. You should find Brad Abram’s blog post(s) on this topic to get the real scoop. The details are complex and subtle.

Rocky

Rocky,

I was hoping you could shed some more light on this, because I hit a wierd problem with static fields.  I was trying to eliminate a static constructor in my application, and I found something weird.

Having a field declared as such:
private static List<object> myList = new List<object>();

I would expect to hit the problem you describe.  The only cavet is that when I checked with Reflector.Net to ensure my static ctor was gone, I found that the above produces this code:

private static List<Object> myList;

static MyClass() {
    myList = new List<object>();
}

So is that actually what the compiler is doing, or is that how Reflector is interperating it?  I'm confused now, because based on your comments above I wouldn't expect the code genereated above.  So something is fishy.

Thanks
Andy

You tell me…

Clearly this stuff is complex, and there may be differences between .NET 1, 2 and 3?

I know there is a perf consequence to having a static constructor (cctor) in a class, and so they should be avoided.

It would appear then, that you can force initialization in two ways:

1.       Implement a cctor and pay the perf cost

2.       Somehow set a static field to a value

The _dummy field is an attempt (that works) to go with option #2.

Of course this doesn’t appear to match with what reflector is showing (Andy was it?), so that’s confusing – and I don’t have an answer for that…

Rocky

Rocky,

The link you gave us (http://msdn2.microsoft.com/en-us/library/aa645758(VS.71).aspx), says:

and gives an example with an empty static constructor..

so... what's with that _dummy field ;-)

I don’t want to declare and initialize propertyinfo in different locations. Or at least I don’t want to force it to be done that way. The whole point of this was/is to reduce and simplify code.

Rocky