CSLA .NET 3.8.4 is now available as a beta download. This is mostly a bug fix release to address a few issues from 3.8.3, plus some ASP.NET MVC work.
Version 3.8.4 targets .NET 3.5 and Silverlight 3 (though with a little effort it works with Silverlight 4 as well).
See the change log for a list of changes. There aren’t many, but if they affect you then they are important.
The only feature change in 3.8.4 is that most of the new ASP.NET MVC 2 support from CSLA 4 has been back-ported to 3.8. This means that the Csla.Web.Mvc project now targets and supports ASP.NET MVC 2, and provides more features and functionality that was there in 3.8.3.
This is a stable beta, given the small number of changes (other than the MVC support). So if you are affected by any of the issues listed in the change log I strongly recommend moving from 3.8.3 to 3.8.4 beta to test and utilize the changes.
Well done with all the hard work and the excellent improvements that come with CSLA4 !!
We really appreciate your efforts and commitment to CSLA.
I have a quick question, regarding your blog post regarding CSLA v3.8.4. You stated that v3.8 targets Silverlight 3 “(though with a little effort it works with Silverlight 4)”.
Where can I find more information about specifically what the changes for Silverlight 4 is? I was unable to track down what I need to do to move a CSLA 3.8 project targeting Silverlight 3 to Silverlight 4 from a CSLA perspective.
Thanks,
Jaans
*Bump*
I'm using 3.8.x in Silverlight 4 and would really appreciate any input on any work I need to do better support this version of CSLA in SL4.
Although I haven't seen any obvious issues and it appears to be working fine, I'd really like to avoid them before I've deployed to my customers.
Many thanks
If it works then it works 
3.8 officially targets .NET 3.5 SP1 and SL3. Using it in .NET 4 and SL4 is fine, but isn't something I currently plan to spend time on myself.
(though I've given some thought to a 3.9 that does target .NET 3.5 SP1 and SL4 in VS10 - but even that will be a straight update done to save people the trouble of doing the solution upgrade necessary to use 3.8 now)
Did a deployment today and it turns out there we're quite a couple issues:
My recommendation in CSLA 4 is that the PropertyInfo<T> fields be public. This is basically a requirement for Silverlight, and should be done in .NET for consistency.
It is likely that there is an exception from the connection issue, but somewhere your code isn't checking the async e.Error result value. I sometimes forget to check it too - just use e.Object and don't check e.Error - but that's actually a bug, because when an error does occur it is basically invisible...
This is a case, btw, where having a custom ViewModel<T> base class is helpful. Once you know how your UI works (in terms of displaying error info), you can override the on error method in your viewmodel base class and properly handle the error. That covers almost all the async data portal error issues you are likely to encounter.
Should we go ahead and start making the PropertyInfo<T> fields Public in Csla 3 also? Sooner or later I have to move to Csla 4.
[quote user="RockfordLhotka"]My recommendation in CSLA 4 is that the PropertyInfo<T> fields be public.
Should we go ahead and start making the PropertyInfo<T> fields Public in Csla 3 also? Sooner or later I have to move to Csla 4.
I make them public in 3.8 when building SL apps, yes. It is simpler/safer than the _forceInit hack.
In 3.8 there's a tiny risk - if someone tampered with the Index property (I think that's the one) they'd mess up serialization or worse. In CSLA 4 that property isn't public, so that risk is essentially eliminated. But I think it is a small risk anyway - who's really going to start messing around with those fields?
Not me - no way. :) And I am SL all th way.
Hi Rocky
I just came across another issue that popped up as a result of making the static PropertyInfo<T> fields public.
I get the following exception:
Csla.PropertyLoadException was unhandled by user code
Message=Property load or set failed for property WorkOrderId (Attempt by method 'Csla.Core.FieldManager.FieldDataManager.ForceStaticFieldInit(System.Type)' to access field XXXX+Criteria.IdProperty' failed.)
StackTrace:
at Csla.Core.ManagedObjectBase.LoadProperty[P](PropertyInfo`1 propertyInfo, P newValue)
at XXXX.Criteria.set_Id(Int32 value)
at XXXX.Criteria..ctor(Int32 Id, Nullable`1 ______Date)
at XXXX.GetChild(YYYY yyyy, EventHandler`1 callback)
at YYYY.RefreshXXXXAfter______DateChange(YYYY yyyy, RuleArgs ruleArgs)
at Csla.Validation.RuleMethod`2.Invoke(T target)
at Csla.Validation.RuleMethod`2.Csla.Validation.IRuleMethod.Invoke(Object target)
at Csla.Validation.ValidationRules.CheckRules(List`1 list)
We have for quite some time now, been declaring our Criteria classes as nested classes inside our business object and have it scoped to be internal. Also, we use managed PropertyInfo<T> properties for our Criteria classes also (as opposed to the old private fields with OnGetState/OnSetState overrides).
This is happening inside the private setter of a Criteria : CriteriaBase object. In this a scenario where a business rule might trigger the updating of a child object, so the call stack originals from a ValidationRule (not that I'm sure whether that bit is relevant). The trigger for the validation rule originates from Silverlight, so that obviously may be the reason for the scoping issue because when I change my criteria class declaration to be scoped public the exception goes away.
Could there be a bug LoadProperty implementation, or should we change our ways and rather declare our criteria classes to be scoped public since using publicly scoped PropertyInfo<T> declarations for our properties when used in Silverlight?
I hope this makes sense,
Jaans
PS: Just ordered the MVVM video series.
Jaans, is this occurring when you are using 3.8.4?
Gulp...I got an earie and embarassing feeling when I read your reply.
Turns out that it wasn't the latest version 3.8.4.
My apologies, I'll check that again with the latest version first en revert back when I have a result either way.
Thanks for helping
It is still possible you'll encounter the problem with 3.8.4.
Silverlight 4 appears to have changed the way static fields are initialized, and also the SL4 JIT compiler appears to be smart enough to "optimize away" the _forceInit code trick.
So in SL4 the only truly reliable way to get your PropertyInfo<T> fields initialized appears to be to make them public. I suspect the type they are contained within (your criteria type) needs to be public as well - this is all due to reflection limitations with Silverlight.
Thanks Rocky
Yep... it still happens with 3.8.4 (and will likely happen with CSLA 4.0.0 too I guess).
I can definitely say that it's a SL4 thing because this piece of functionatlity worked perfectly fine when it was still running as a Silverlight 3 application. Clearly it relates to the more aggressive SL4 JIT compiler as you say.
It's a pity that it breaks this, because now our public API is about to get a significant increase in members as we change the criteria classes to be scoped public. Hmmm, will need to make changes to our code generation too.
Thanks for the help,
Jaans
I suppose you could try and make the forceInit code more complex - try and trick the JIT compiler into thinking you are actually using the field for something?
Copyright (c) Marimer LLC