-
The CSLA source code is now C# only, though there is a community project to maintain a VB.NET source code version. I am not sure how up to date this is, but you can use CSLA irrespective of it's source code language with any .NET language.
-
It is the ExtendedSafeDataReader that converts nulls into empty strings, not the FieldManager LoadProperty methods. If you can post some of the code that is being used, may be able to show exactly where the problem lays.
-
I can only answer your first question, because you get a new object back when you perform a save, this object is passed into the SavedEventArgs as the NewObject parameter, so something like this: DirectCast(e.NewObject, Company).CompanyId will get the new value correctly.
-
The reason your validation rules are running on creation is because the base implementation of Child_Create() runs ValidationRules.CheckRules() whereas a Child_Fetch() does not unless specifically added by your code. Given that these fields are required, it is probably a good thing the validation rules are running but that all depends on your use case
-
The real reason to avoid doing this is because if at some point in the future 100 of the objects need a similar behavior and the other 50 don't then it can make it very difficult to implement. However, hopefully the psudeo-code below will at least guide in the right direction. The use of the interface is really important, and I would not recommend
-
Because you are using the properties directly to assign the values, the object is being marked as dirty. You either need to wrap those statements around a U.BypassPropertyChecks() call or call MarkAsOld directly on the User object before adding it to list. This obviously is depends on what access you have to the object though. This will also mean that
-
Some of the most difficult challenges that my team experienced when first starting to work with CSLA is that it is a very much use-case & behavior oriented platform. This can result in what is perceived by many to be a duplication of code or objects, however, once you get your head around that it makes building your objects much easier. Given the
-
As part of the ApplicationContext there is a property called ExecutionLocation that tells you if you are on the client, server or one silverlight. There is also a LogicalExecutionLocation property, but I'm unsure as to difference between the two and I'm sure that ExecutionLocation worked for this previously. So a simple check in your method
-
I'm all for smart rules, and that was a solution that was suggested internally. Where we have a property that marks the object to be in a certain state, in which all rules would need to check for and if in that state then bypass the rule that changes / sets default values. We would then have to ensure that property was set before call CheckRules
-
We are using CSLA 3.8.x and want to build some validation rules that configure some default values whenever a property has changed. We are using validation rules as has been suggested on this forum, so to minimize the amount of code that goes into the setter methods in our properties. However, this causes the problem that when we run the validation