The CSLA .NET framework is an application development framework that reduces the cost of building and maintaining applications.

The framework enables developers to leverage the power of object-oriented design as the basis for creating powerful applications. Business objects based on CSLA automatically gain many advanced features that simplify the creation of Windows, web, service, and mobile interfaces. CSLA .NET allows great flexibility in object persistence, so business objects can use virtually any data sources available. The framework supports 1-, 2- and n-tier models through the concept of mobile objects. This provides the flexibility to optimize performance, scalability, security and fault tolerance with no changes to code in the UI or business objects. The ApplicationContext object must be managed differently in ASP.NET than other environments. In CSLA 4, Csla.dll doesn't (can't) reference System.Web.dll, so correct management of ApplicationContext for ASP.NET is in Csla.Web.dll. All ASP.NET hosted code must reference Csla.Web.dll to function correctly in CSLA 4. More info... Edit

.NET: How do I configure WCF?

WCF configuration can be very complex. There are many options, and they interact with each other in complex ways. The Microsoft Patterns and Practices group wrote a WCF configuration guide, which is perhaps the best resource available. Edit

.NET: How do I set up WCF to use binary XML?

This forum post has details on the configuration. Edit

SL: How do I implement compression in the Silverlight data portal?

The CSLA .NET for Silverlight data portal has hooks specifically designed to allow you to plug in a compression engine for data sent to/from the server. This is almost required, because the XML generated by the DataContractSerializer when serializing business objects gets very large fast! read more... Edit

.NET: How do I use compression for the WCF data portal channel?
There are third party WCF bindings that implement compression. I recommend using one of those bindings. This thread discusses one option. Edit

.NET: How do I use compression for the Remoting data portal channel?
This thread has information about one solution. Edit

SL: Can I (should I) use binary XML with the Silverlight data portal?
CSLA .NET 3.8 uses binary XML on your behalf. You should probably still use compression on the data (the previous topic in this FAQ), and you should probably configure your WCF endpoint and client to use binary XML as well. This thread has more information, along with performance data around the use of binary XML, compression and both combined. Edit

Data Size Limit in IIS 7

IIS 7 includes a new data size limit setting that may block transfer of large object graphs through the data portal. To overcome this issue, raise the limit:
<system.webServer> <security> <requestFiltering> <requestLimits maxAllowedContentLength="209715200" ></requestLimits> </requestFiltering> </security> </system.webServer>

Edit

SL: I get Maximum request length exceeded on data portal calls

The default size limits for WCF messages between Silverlight and ASP.NET are too low for any practical application scenarios when using the data portal. You need to up the limits by changing the WCF configuration in the client and server config files. For example:

Server
<system.serviceModel> ...... <basicHttpBinding> <binding name="basicHttpBinding_IWcfPortal" maxReceivedMessageSize="2147483647" <readerQuotas maxBytesPerRead="2147483647" maxArrayLength="2147483647" maxStringContentLength="2147483647" maxNameTableCharCount="2147483647" maxDepth="2147483647"/> </binding> </basicHttpBinding> ...... </system.serviceModel> <system.web> ...... <httpRuntime maxRequestLength="2147483647"/> ...... </system.web>

Client
<basicHttpBinding> <binding name="basicHttpBinding_IWcfPortal" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647> </binding> </basicHttpBinding>

Edit

How do I get server-side exception information on the client?

On the Windows/.NET platform the data portal returns a DataPortalException and the original exception is exposed as a BusinessException property. On the Silverlight side things are a bit different, because it is not possible to serialize the actual exception object(s) from .NET back to Silverlight. Remember that SL is a different runtime and platform from .NET and the types don't always line up. What we do instead, to provide as much information as we can, is we run through the exception chain on the server side and rip out most of the public property values. Those values are put into a WcfErrorInfo object chain, which looks somewhat similar to the original exception chain. This object chain is available as an ErrorInfo property on the Silverlight DataPortalException object.

Does the object graph get serialized when using the local data portal?
In version 3.5 and higher, by default the object graph is serialized when you invoke the data portal on a root object. Even in local mode the object graph is serialized once, to handle the case where the database throws an error in the middle of updating a set of objects. In that case, your object graph would be broken because some objects would have new (but now invalid) primary key values and timestamp values. That scenario has never been a problem with a remote data portal, because the original object graph was still on the client, and the broken graph on the server is essentially discarded. But for a long time (everything up to 3.5 basically) the local data portal would leave you with a broken object graph. In some of my older books I recommended writing UI code to clone the object graph and to have a try..catch block to solve this issue - but that's really not good, because it isn't a UI concern, and because most people didn't do this extra work. So in 3.0 I added the option for the data portal to make the problem go away, but you had to turn it on (with the AutoCloneOnUpdate setting). And in 3.5 I changed the AutoCloneOnUpdate default to true, so the data portal does the right thing (cloning the object graph) by default, and you need to turn it off if you want the older (arguably broken) behavior.