There is now a CSLA .NET MCP server that you can use if you are using AI LLMs such as GitHub Copilot. I've been using (and enhancing) this for the past few weeks and it is a serious benefit when bu...

Thanks to a PR from Stefan, the main branch now builds for .NET 10. This does mean that if you want to build the main branch you'll need the .NET 10 sdk installed, and possibly also VS26 Insiders (...

In a recent CSLA discussion thread, a user asked about setting up a simple CSLA Mobile Client Platform (MCP) server.

One of the most powerful features of CSLA .NET is its business rules engine. It allows you to encapsulate validation, authorization, and other business logic in a way that is easy to manage and mainta...

SQL Saturday is a one-day conference for data professionals who want to learn how to elevate their careers on the Microsoft Data Platform.

What's Changed Release notes Bump Google.Protobuf from 3.29.2 to 3.29.3 in /Source by @dependabot in #4434 Bump Grpc.Tools from 2.68.1 to 2.69.0 in /Source by @dependabot in #4435 Bump Nerdbank.Gi...

I just pushed a beta of the upcoming CSLA 9.1.0 release. This includes a bunch of bug fixes and behavioral updates. You can see the issue board here: https://github.com/orgs/MarimerLLC/projects/30 ...

The CSLA data portal originally treated 2- and 3-tier differently, primarily for performance reasons. Back in the early 2000’s, the data portal did not serialize the business object graph in 2-tier scenarios. That behavior still exists and can be enabled via configuration, but is not the default for the reasons discussed in this post. Passing the object graph by reference (instead of serializing it) does provide much better performance, but at the cost of being behaviorally/semantically different from 3-tier. In a 3-tier (or generally n-tier) deployment, there is at least one network hop between the client and any server, and the object graph _must be serialized_ to cross that network boundary. When different 2-tier and 3-tier behaviors existed, a lot of people did their dev work in 2-tier and then tried to switch to 3-tier. Usually they’d discover all sorts of issues in their code, because they were counting on the logical client and server using the same reference to the object graph. A variety of issues are solved by serializing the graph even in 2-tier scenarios, including: 1. Consistency with 3-tier deployment (enabling location transparency in code) 2. Preventing data binding from reacting to changes to the object graph on the logical server (nasty performance and other issues would occur) 3. Ensuring that a failure on the logical server (especially part-way through the graph) leaves the graph on the logical client in a stable/known state There are other issues as well - and ultimately those issues drove the decision (I want to say around 2006 or 2007?) to default to serializing the object graph even in 2-tier scenarios. There is a performance cost to that serialization, but having _all_ n-tier scenarios enjoy the same semamantic behaviors has eliminated so many issues and support questions on the forums that I regret nothing.

What's Changed Initialize session id cookie on server path by @rockfordlhotka in #4470 Full Changelog: v8.2.8...v8.2.9

CSLA 9 release candidate 3 is now online in NuGet. This includes some bug fixes and work around MAUI. I think we're really narrowing in on the CSLA 9 release at this point, so please test and let u...

What's Changed Fix Blazor context manager issue by @rockfordlhotka in #4239 Restore app context if operation fails w/ no local clone by @rockfordlhotka in #4280 Cherry pick: Fix for #3581, Ensure u...

Hello everyone! I am happy to announce that CSLA 9 release candidate 1 is now available in NuGet. We are at the point with version 9 where the only changes expected are to fix bugs found by you, or...