Rockford Lhotka

 Monday, April 5, 2010

The first preview of the new CSLA 4 business rules subsystem will be available soon from

Of course there are a lot of other changes to CSLA .NET in this preview, so make sure to carefully read the change log. Although there are a lot of breaking changes, most of them have pretty minimal impact on people who are already using the 3.8 coding style for classes. Except for the business rules – that impacts everyone.

This is a major change to the way business and validation rules work, with some pretty amazing new capabilities as a result.

The next preview will roll authorization rules into this as well, and that’ll be the last major change for CSLA 4.

The business rule changes apply to both Silverlight and .NET – as always the idea is that the vast majority of your business code should be the same regardless of platform.

I’d like to summarize the primary changes from 3.8 to 4 in regards to business and validation rules.

Simple changes

The simplest change is that the ValidationRules property in BusinessBase is now named BusinessRules. Also, the Csla.Validation namespace has been replaced by the Csla.Rules namespace.

If you are using DataAnnotations validation attributes in 3.8, they continue to work in 4 without change.

That was the easy part. Now for the interesting changes.

Rule classes

Rule methods are replaced by rule classes. This means a 3.8 rule like this:

private static bool MyRule<T>(T target, RuleArgs e) where T : Customer
  if (target.Sales < 10)
    e.Description = "Customer has low sales";
    e.Severity = RuleSeverities.Information;
    return false;
    return true;

becomes a class like this:

private class MyRule : Csla.Rules.BusinessRule
  protected override void Execute(RuleContext context)
    var target = (Customer)context.Target;
    if (target.Sales < 10)
      context.AddInformationResult("Customer has low sales");

It is the same basic rule, but packaged just a little differently. Rule types must implement IBusinessRule, but it is easier to inherit from BusinessRule, which provides a set of basic functionality you’ll typically need when implementing a rule.

The most important thing to understand is that the RuleContext parameter provides input and output for the Execute() method. The context parameter includes a bunch of information necessary to implement the rule, and has methods like AddErrorResult() that you use to indicate the results of the rule.

There’s one coding convention that you must follow: the protected properties from BusinessRule must never be changed in Execute(). I wish .NET had the ability to create an immutable type – a class where you could initialize properties as the object is created, and then ensure they are never changed after that point. But such a concept doesn’t exist, at least in C# or VB. But that is what you must do with rule objects. You can set the properties of the rule object as it is created. After that point, if you change properties of the rule object you are going to cause bugs. So do not change the properties of a rule in Execute() and you’ll be happy.

AddRule Method

In the Customer business class you still override AddBusinessRules(), and that code looks like this:

protected override void AddBusinessRules()
  BusinessRules.AddRule(new MyRule { PrimaryProperty = SalesProperty });

The new AddRule() method accepts an instance of an IBusinessRule instead of a delegate like in 3.8. This one instance of the rule is used for all instances of the business object type. In other words, exactly one instance of MyRule is created, and it is used by all instances of Customer. You must be aware of this when creating a rule class, because it means you can never alter instance-level fields or properties after the rule is initialized. If you do alter an instance-level field or property, you’ll affect the rule’s behavior for all Customer objects in the entire application – and that’d probably be a very bad thing.

Most rule methods that require a primary property will actually require it on the constructor. For example, look at the Required and MaxLength rules:

protected override void AddBusinessRules()
  BusinessRules.AddRule(new MyRule { PrimaryProperty = SalesProperty });
  BusinessRules.AddRule(new Csla.Rules.CommonRules.Required(NameProperty));
  BusinessRules.AddRule(new Csla.Rules.CommonRules.MaxLength(NameProperty, 20));

The result is the same either way, but when you are writing your rules it is typically best to explicitly require a primary property on the constructor if you plan to use the primary property value. Later I’ll talk about per-object rules that have no primary property.

You should also notice that the properties are always Csla.Core.IPropertyInfo, not string property names. The new business rule system requires that you use PropertyInfo fields to provide metadata about your properties. This syntax has been available since CSLA 3.5, and for my part I haven’t created a business class without them for years. This is one part of a larger effort to eliminate the use of string property names throughout CSLA and CSLA-based business code.

Invoking Rules

In the previous AddRule() call, the PrimaryProperty property of the rule is set to SalesProperty. This is what links the rule to a specific property. So when the Sales property changes, this rule will be automatically invoked. As in 3.8, all rules are invoked (by default) when an object is created through the data portal, and can be invoked by calling BusinessRules.CheckRules(). And you can invoke rules for a property with BusinessRules.CheckRules(SalesProperty) – though you should notice that CheckRules() now requires an IPropertyInfo, not a string property name.

If you don’t provide a PrimaryProperty value as shown in this example, the rule method is associated with the business type, not a specific property. This means that the rule will run when CheckRules() is called with no parameter, or when the new CheckObjectRules() method is called to invoke rules attached to the business type.

In summary, there are now three CheckRules() overloads:

  1. CheckRules() – checks all rules for an object
  2. CheckObjectRules() – checks all rules not associated with a specific property (object rules)
  3. CheckRules(property) – checks all rules for a specific property

The same concepts of priority and short-circuiting from 3.8 apply in 4.

InputProperties and InputPropertyValues

You can write that same rule just a little differently, making it unaware of the Target object reference:

public class MyRule : Csla.Rules.BusinessRule
  public MyRule(Csla.Core.IPropertyInfo primaryProperty)
    : base(primaryProperty)
    InputProperties = new List<Csla.Core.IPropertyInfo> { primaryProperty };

  protected override void Execute(RuleContext context)
    var sales = (double)context.InputPropertyValues[PrimaryProperty];
    if (sales < 10)
      context.AddInformationResult("Sales are low");

This is a little more complex and a lot more flexible. Notice that the rule now requires a primary property, which is actually managed by the BusinessRule base class. Also notice that it adds the primaryProperty value to a list of InputProperties. This tells CSLA that any time this rule is invoked, it must be provided with that property value.

In the Execute() method notice how the sales value is retrieved from the context by using the InputPropertyValues dictionary. This dictionary contains the values from the business object based on the properties in the InputProperties list. A rule can require many property values be provided. Of course the rule will only work with objects that actually have those properties!

Because this rule will work with any object that can provide a double property value, the class is now public and could be placed in a library of rules.

The AddRule() method call in Customer must change a little:

protected override void AddBusinessRules()
  BusinessRules.AddRule(new MyRule(SalesProperty));

As before, the PrimaryProperty property is being set, but this time it is through the constructor instead of setting the property directly. This is because the rule now requires the primary property value, and can only work if it is supplied.

Business Rules: Rules that modify data

The CSLA 4 rules system formally supports business rules. Really 3.8 did too, but it was a little confusing with the terminology, which is why ValidationRules is now called BusinessRules – to avoid that confusion.

The RuleContext object now has an AddOutValue() method you can use to provide an output value from your rule:

context.AddOutValue(NameProperty, “Rocky”);

When the rule completes, any out values are updated into the business object using the LoadProperty() method (so there’s no circular loop triggered).

This AddOutValue() technique is safe for synchronous and asynchronous rules, because the business object isn’t updated until the rule completes and control has returned to the UI thread.

If you are creating a synchronous rule, the RuleContext does have a Target property that provides you with a reference to the business object, so you could set the property yourself – just remember that setting a property typically triggers validation, which could cause an endless loop. Overall, it is best to use AddOutValue() to alter values.

Validation Rules: Errors, Warnings and Information

As in 3.8, CSLA 4 allows validation rules to provide an error, a warning or an informational message. The RuleContext object has three methods:

  1. AddErrorResult()
  2. AddWarningResult()
  3. AddInformationalResult()

Each of these methods takes a string parameter which is the human-readable text to be displayed. A rule should only call one of these methods. If the rule calls them more than once, only the last one will have effect.

If AddErrorResult() is called, the rule is returning a failure result, and the business object will become invalid (IsSelfValid will be false).

If no method is called, or AddWarningResult() or AddInformationalResult() is called the rule is returning a success result and the business object will not become invalid. This is basically the same as the 3.8 behavior.

Dependent Properties

The concept of dependent properties is quite different in the new system. Instead of an AddDependentProperty() method, a rule now indicates the properties it affects. This can be coded into the rule itself or specified when AddRule() is called. Either way, what’s happening is that every rule object maintains a list of AffectedProperties for that rule.

When a rule completes a PropertyChanged event is raised for every property in AffectedProperties, as well as any properties altered through AddOutValue().

It is also important to realize that, with an async rule, all properties in AffectedProperties will be marked busy when the rule starts, which typically means the user will see a busy animation (if you are using the PropertyStatus control) to show that the property has some outstanding operation running.

Rule Sets

This is a major new feature of the rules system that is designed to support web applications where multiple customers/clients/organizations are sharing the same virtual root and application. In that case it might be necessary to have different business rules for each customer/client/organization. Rule sets are a way to accomplish this goal.

When you call BusinessRules.AddRule(), the rules are added to a rule set. Normally they are added to the default rule set, and if you only need one set of rules per type of object you can just be happy – it works. But if you need multiple sets of rules per type of object (such as one set of rules for customer A and a different set for customer B), then you’ll want to load each set of rules and attach those rules to your business object type.

This is done by changing the BusinessRules.RuleSet property. For example:

protected override void AddBusinessRules()

  // add rules to default rule set

  // add rules to CustA rule set
  BusinessRules.RuleSet = "CustA";

  // add rules to CustB rule set
  BusinessRules.RuleSet = "CustB";

  // use default rule set
  BusinessRules.RuleSet = “default”;

This code loads rules into three rule sets: default, CustA and CustB. It is up to you to set the RuleSet property to the correct value for each business object instance.

To set the rule set, set the BusinessRules.RuleSet property, then make sure to call BusinessRules.CheckRules() to apply the new set of rules.

The RuleSet value is serialized along with the state of the business object, so you can (and typically will) set the RuleSet property in your DataPortal_Create() and DataPortal_Fetch() methods, and that rule set will be used through the life of the object. I expect the most common scenario will be to set the RuleSet based on the identity of the current user, or some context value in Csla.ApplicationContext.ClientContext.

Per-Object Rules

Finally, it is possible to have rules that are not attached to a specific primary property. These rules are attached to the business object. For example:

protected override void AddBusinessRules()
  BusinessRules.AddRule(new MyObjectRule());

private class MyObjectRule
  protected override void Execute(RuleContext context)
    var target = (Customer)context.Target;
    // check rules here

Notice that the AddRule() method has no primary property specified. Because there’s no primary property, the rule is attached to the business object itself. Normally this type of rule is a private rule in the business class, and uses the business object’s properties directly. But you can specify input and affected properties, as well as provide output values as discussed earlier.

Per-object rules are run in two cases:

  • You call BusinessRules.CheckRules()
  • You call BusinessRules.CheckObjectRules()

Per-object rules are not run automatically when properties change. So if you don’t invoke them, they won’t run.

Async Rules

One of my primary goals in designing the new rule system is to provide a lot of consistency between sync and async rules. To this end, both sync and async rules are constructed the same way: by implementing IBusinessRule or subclassing BusinessRule.

But there are some extra restrictions on async rules. Most notably, async rules must get their input values through the RuleContext, and must provide any output values through RuleContext. To help enforce this, the context.Target property is always null in an async rule. This should help prevent the rule from trying to interact directly with the business object.

The reason this is so important, is that I assume an async rule will run some of its code on a background thread. Most of CSLA (and .NET) is not threadsafe, so having multiple threads interact with a business object will cause problems. If the async rule uses the RuleContext as a message to get and return values, CSLA can help ensure processing occurs on the correct thread.

Here’s a simple async rule. It is a little silly, in that all it does is ToUpper() a string value, but it should give you the idea:

public class AsyncToUpper : Csla.Rules.BusinessRule
  public AsyncToUpper(Csla.Core.IPropertyInfo primaryProperty)
    : base(primaryProperty)
    IsAsync = true;
    InputProperties = new List<Csla.Core.IPropertyInfo> { primaryProperty };

  protected override void Execute(Csla.Rules.RuleContext context)
    var bw = new System.ComponentModel.BackgroundWorker();
    bw.DoWork += (o, e) =>
      var value = (string)context.InputPropertyValues[PrimaryProperty];
      context.AddOutValue(PrimaryProperty, value.ToUpper());
    bw.RunWorkerCompleted += (o, e) =>
      if (e.Error != null)

The rule indicates that it is async by setting IsAsync to true in its constructor. This tells CSLA that the rule expects to run some or all of its logic on a background thread, so CSLA does some extra work for you. Specifically, CSLA marks the primary property and any AffectedProperties as busy before the rule starts and not busy when it ends. It also sets up the rule invocation so its results are handled through an async callback within CSLA. And it makes sure the RuleContext.Target property is null.

Next, notice that the InputProperties list is initialized in the rule’s constructor. This is the list of property values the rule requires to operate, and these property values will be provided through the RuleContext to the Execute() method in the InputPropertyValues dictionary.

The Execute() method itself is using a BackgroundWorker to run some code on a background thread. You can use BackgroundWorker or the async DataPortal and they’ll work fine. The one big requirement here is that whatever you use must ensure that the competed callback is on the UI thread. It is your responsibility to make sure the completed callback is on the UI thread (if any). The BackgroundWorker and data portal do this for you automatically. If you use some other async technology you must take steps to make sure this is done correctly.

The AddOutValue() method is used to provide the output value. Remember that the actual business object property isn’t affected until after the rule completes, which is when CSLA is handling the results of your rule on the UI thread (where it can safely update the business object).

The RunWorkerCompleted event is used to handle any async errors. You’d do the same thing with the data portal, handling the FetchCompleted event (or similar). It is important to remember that exceptions occurring on a background thread are lost unless you carry them through. The code shown here is following what I typically do, which is to add an error result from the rule in the case of an async exception.

One last thing to keep in mind: there is exactly one instance of your rule object being used by all instances of a business type. Because of this, the Execute() method must be atomic and stateless. To put it another way, you should never, ever, ever alter any instance-level fields or properties of the rule object from the Execute() method. If you do alter an instance-level field or property of the rule object, that change will affect all business objects, not just the one you are running against right now. And with async rules you’ll run into race conditions and other nasty multi-threading issues. This is really the same restriction I mentioned earlier with sync rules – don’t change rule properties in Execute() – but it is so important that I wanted to reiterate the point here too.

While there are some restrictions on how you construct an async rule, I am pretty happy with how similar sync and async rules are to implement. In fact, all the async concepts (input values, AddOutValue()) work just fine with sync rules too.

Moving from 3.8 to 4

While the new business rules system is somewhat different from the 3.8 implementation, the process of moving from 3.8 to 4 isn’t terribly painful.

  • Every rule method must become a rule class. This is a pretty mechanical process, but obviously does require some work
  • Every use of ValidationRules must be changed to BusinessRules
  • Every AddRule() call will be affected, which is another mechanical change
  • Dependent properties become AffectedProperties on each AddRule() method call

I was able to get the entire unit test codebase changed over in less than 8 hours – and that included changes not only for the business rules, but also for the data portal and several other breaking changes. I don’t mean to trivialize the effort required, but the changes are mostly mechanical in nature, so it is really a matter of plowing through the code to make the changes, which is mostly repetitive and boring, not really hard.


I’m using the major version change from 3 to 4 as an opportunity to make some fairly large changes to CSLA. Changes that enable some key scenarios needed by Magenic customers, and requested by people on the forum explicitly or implicitly. Some effort will be required to upgrade, but I suspect most people will find it well worth the time.

The big changes are:

  • Rule sets
  • Per-object rules
  • Rule objects instead of rule methods
  • Common model for sync and async rules

I’m pretty excited about these changes, and I hope you find them useful!

Monday, April 5, 2010 12:40:05 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, April 2, 2010

This is the first of a series of blog posts I’m putting together as I prepare for the next preview release of CSLA 4. That preview release is coming soon, there are just a couple more things to wrap up, but I want to have the preview out by the .NET 4 launch, which is April 12.

CSLA 4 includes a lot of changes, including some changes to the data portal. This post covers the highlights.

DataPortal methods

Some are relatively small, but might impact existing code.

One example is the removal of the non-generic DataPortal method overloads. Create() is gone in favor of Create<T>().

Another example is that DataPortal_Fetch(object) is no longer a virtual method in the base classes, which means if you are overriding this method you’ll need to remove the override keyword in your code.

The reason for removing the non-generic DataPortal methods is that it makes the criteria parameter for Create/Fetch/Delete more flexible. It is now possible to use any serializable object as a criteria. On .NET this means anything that can be serialized with the BinaryFormatter and/or NDCS. On Silverlight this means anything that can be serialized with MobileFormatter. And this includes primitive types. In short, you can now do this:

var cust = DataPortal.Fetch<Customer>(123);

This eliminates the need for the SingleCriteria<> type, and generally simplifies most data portal calls.

Proxy factory

A more significant change, though one that has no impact unless you want to use it, is the ability to create your own proxy factory. By default the data portal loads the client-side proxy based on the type you specify in your config file – so you can switch between local, WCF, Remoting and other proxies through configuration.

But it is now possible to create a proxy factory by implementing IDataPortalProxyFactory. This factory is responsible for creating the data portal proxy object based on the type of business object being sent through the data portal. Add a key in your config file for CslaDataPortalProxyFactory to specify the assembly qualified type of your implementation and CSLA will use that instead of the default behavior.

The idea is that some applications need to use different app servers or different protocols for different business objects. If you create your own proxy factory, you get the opportunity to examine the business object type (probably using reflection) so you can decide which proxy should be used to talk to an app server for that particular type of object.

Server exceptions

(not implemented yet, but in progress)

Server exceptions are always returned to the client wrapped in a DataPortalException. This is not changing, because the DataPortalException is what allows CSLA to provide you with the full stack trace and other useful information from the server.

However, it is now possible to replace the original server exception with a new exception in your override of DataPortal_OnDataPortalException() or the InvokeError() method of a factory object.

Silverlight flexibility

The Silverlight data portal was not as flexible as the .NET data portal. Specifically, it wasn’t possible to create your own proxy/host channel that totally replaced the WCF proxy/host provided by CSLA. In CSLA 4 you can now create completely custom proxy/host channels for the Silverlight data portal. This means you could, for example, create one that didn’t use WCF at all, but instead used raw TCP sockets. Or more likely, it means you can create a proxy/host that uses a custom third-party WCF binding.

A related change is to the MobileFormatter, which now has the ability to provide you with completely serialized data (the default), or to provide you with the serialized data in an intermediate DTO form. If you get the DTO form, you are getting an object graph that consists only of objects which can be serialized using the DataContractSerializer (or similar serializers). This opens up a lot of flexibility, because it means you can apply other serializers (perhaps from third parties) to the DTO graph. In some cases this

Design time data

VS10 has a new design time data model, so the old design time data behaviors have been removed from the data portal. This won’t break any code, but if you were using the design time data generation concept, it is now gone and your methods won’t be invoked.

.NET compression sample

There’s a new sample for .NET that shows how to use a standard compression library (of your choice) to compress the data that goes over the data portal. I think it is probably best to get a WCF binding that does the compression, but if you want an alternative this sample shows you how to do it.

Overall the data portal continues to offer the same n-tier and network transport flexibility it has always provided, but these changes make common scenarios easier to implement, and enable some important advanced scenarios that have been frequently requested.

Friday, April 2, 2010 11:36:03 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Saturday, March 20, 2010

As I’ve said before, I love Windows Home Server. While it has many useful features, the core feature is automatic nightly image backups of my computers.

Of course a backup is only useful if you can do a restore, which I’ve done 2-3 times, and which has easily paid for WHS each time.

I recently got my PDC laptop (Acer Aspire 1420P) into a bad spot with some pre-release software. This happens, and I wasn’t worried because I have WHS backups. Just 60-90 minutes and I can have the machine back exactly the way it was at a previous point in time.

Except I ran into a snag. It turns out that the WHS restore CD from 2007 bluescreens when it tries to boot on the 1420P. OK, no problem, I downloaded the newer restore image from Microsoft, created a new bootable CD and got the restore app running.

But then the restore app didn’t find the LAN driver. Without a network driver you can’t restore – the network is how the restore app communicates with WHS. On the advice of friends I got the drivers off the latest WHS backup of my laptop as described here. Unfortunately they are 64 bit drivers, and the WHS restore app is a 32 bit app, so the drivers are useless.


Some frantic web searching ensued, and finally I stumbled across an article that suggested the 1420P has much the same hardware as the 1410. I had nothing to lose, so I grabbed the Lan_Atheros_1.0.0.19_Vistax64Vistax86_A driver from the Acer support website – this is the LAN driver for the Aspire 1410 – and put it on a USB thumb drive where the WHS restore app could find it.

And that did the trick!! The WHS restore app found the driver, loaded it, and 48 minutes later my tablet was restored to a previous image and it is now working perfectly.

Saturday, March 20, 2010 11:15:40 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Thursday, March 18, 2010

I have an app that uses the SL4 RichTextBox control. It is a nice control, and I’ve been enjoying using it. I even went so far as to convert thousands of rows of HTML to Xaml in my database for use with the RTB.

But the control has a couple changes in the new release candidate that I’m having to work around – and if they are not bugs then I’ll have to write a little app to clean the data in my database.

Prior to the RC the minimum value you could set to the Xaml property was “<Section />”. This was (and is) a pain, because it won’t accept null or string.Empty – so if your actual value is null you need to detect that and change it before trying to set the Xaml property.

But in the RC the minimum value is now “<Section xmlns=\"\"/>”. Not a huge change, but it broke my app of course.

The bigger issue is that prior to the RC the RTB allowed the TextDecorations attribute on the <Section> element. And in fact it generated this attribute when it created Xaml.

In the RC the TextDecorations attribute is no longer valid. It isn’t generated, but more importantly it isn’t allowed, so all my Xaml data is invalid.

This is a bit of code that fixes both issues:

string xaml;
if (e.NewValue == null)
  xaml = string.Empty;
  xaml = e.NewValue.ToString();
// RTB won't accept an empty string, so if the value is empty/null
// replace it with the minumum necessary Xaml
if (string.IsNullOrWhiteSpace(xaml))
  xaml = "<Section xmlns=\"\"/>";
// RTB used to support TextDecorations, but now doesn't, so that value
// must be removed to avoid a crash
var pos = xaml.IndexOf(" TextDecorations=");
if (pos >= 0)
  var closeQuote = xaml.IndexOf("\"", pos);
  closeQuote = xaml.IndexOf("\"", closeQuote + 1);
  xaml = xaml.Remove(pos, closeQuote - pos + 1);
return xaml;

In this case e.NewValue is the Xaml text I’m hoping to put into the control, and the xaml field ends up holding the corrected result.

I’m sure other people moving from the beta to the RC will encounter this same issue. I’m rather hopeful that the TextDecorations thing is a bug so I don’t have to fix all my data, but I suspect it is an intentional breaking change…

Thursday, March 18, 2010 7:25:40 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, March 16, 2010

Hopefully this can save someone some time. I spent a couple hours setting up a virtual machine and installing the Windows Phone 7 dev tools, only to find that the phone emulator won’t run in a virtual machine. It turns out that this is because the emulator is a virtual machine and you can’t run a virtual machine in a virtual machine.

Tuesday, March 16, 2010 10:45:59 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, March 9, 2010

From Scott Wiltamuth, Product Unit Manager for Visual Studio Languages:

VB and C# Coevolution

Tuesday, March 9, 2010 10:47:11 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Thursday, March 4, 2010

MCsla is a prototype that takes SQL Server Modeling (aka “Oslo” and “M”) and CSLA .NET, using them to create an end-to-end story. This story goes like this:

  1. Developer creates a business database for business data
  2. Developer writes concise DSL code
  3. Developer “compiles” DSL code into the SQL Server Modeling repository
  4. End user executes a runtime application, which dynamically creates a UI, business layer and data layer that uses the business database – all this based on the compiled DSL metadata stored in the repository

This saves the developer from a lot of work. In fact the developer writes perhaps 5% of the code they would have written to create the UI, business layer and data layer by hand.

See my discussion of the concepts and prototype in a three part video series:

Exploring SQL Server Modeling through MCsla

You can see the MCsla code in the CSLA .NET repository (web view) or grab it using any svn client from svn://

Thursday, March 4, 2010 11:06:23 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Monday, March 1, 2010
Monday, March 1, 2010 3:04:57 PM (Central Standard Time, UTC-06:00)  #    Disclaimer

Joost van Schaik spent some time figuring out how to get CSLA .NET 3.8.2 to work with Silverlight 4 – which takes a little effort because SL4 changes the way WCF proxies are referenced in the client config file. It is such an odd change that I rather suspect it might be a bug in SL4, but I guess we’ll see what happens as it gets closer to release.

He also wrote a nice blog post summarizing the steps required, which will probably be useful to a number of people:

.NET by Example: Running CSLALight 3.8.2 under .NET 4 and Silverlight 4

Thank you Joost!

Monday, March 1, 2010 3:01:48 PM (Central Standard Time, UTC-06:00)  #    Disclaimer