Rockford Lhotka's Blog

Home | | CSLA .NET

 Wednesday, March 28, 2018

Power BI is a pretty amazing tool, even for data analysis novices like me. The ability to take data from an Excel spreadsheet and create useful and compelling dashboards as a power user is really wonderful!

However, I don't create such a dashboard all that often, and I find that each time I do it I fall over one particular issue: how to connect my PBI report to a dataset that can auto-refresh.

My dataset is an Excel file in O365 SharePoint (actually in a folder/site managed by Microsoft Teams). In theory it is easy to have PBI connect to such a spreadsheet, and when the report is published to PBI in the web it can be set to auto-refresh the data daily, weekly, etc.

In practice however, this is fraught with peril. The instructions commonly available from Microsoft and other blogs leave out a couple key issues that (I find at least) derail the process and lead to hours of frustration.

I use Power BI Desktop to create my report. So step 1 is to connect to the Excel file hosted in O365 SharePoint. And it is step 1 where things go wrong, because there are so many different ways to connect to a spreadsheet, and so many URL variations for a spreadsheet hosted in SharePoint - most of which won't actually work in the end.

But what's worse, is that all these myriad variations work from Power BI Desktop, so you are fooled into thinking all is well. When in reality, after you publish the report to PBI in the web it will fail! Very frustrating!

My colleague Scott Diehl and I spent some time this afternoon sorting through what works and what only appears to work, and I am documenting it in this blog post so next time I need to create a dashboard I'll have a place to find the answer without re-learning it.

So here's the thing. I have this spreadsheet in Teams.

And if I click on the "Open in SharePoint" link I can see it in O365 SharePoint via the browser.

If I click the "Copy Link" button here I get a link to the file, such as:

And you can use that link to add a dataset to PBI Desktop and it work great.


So instead what you must do is open the spreadsheet in actual desktop Excel. Not in Excel Online, not in O365 SharePoint, but in actual Excel.

Then go to the File tab in the ribbon and you should see something like this.

Notice the text I've highlighted. Left-click on this and choose "Copy Link to Clipboard". The result is a URL like this:

This is just a different URL to the same exact file, but this URL is one that PBI Web will actually accept.

Note: You do need to remove the ?web=1 bit from the end of the URL before using this to create your dataset in PBI Desktop.

From here you can create your report and dashboard, and publish to PBI Web. Then in PBI Web you can edit the dataset to provide PBI Web with your organization credentials, and to set up a refresh schedule for the data:

One final note. If you do what I did, and create your report and dashboard using the first style of URL that works in Desktop but not Web, you are not totally out of luck. In that case, follow the above steps to get the functional URL from Excel, and then in PBI Desktop you can edit the dataset's source.


That'll allow you to replace the broken URL with the working URL, without having to recreate your entire report or lose your work.

Wednesday, March 28, 2018 1:27:54 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Saturday, March 24, 2018

tl;dr: We're just starting on the biggest revolution in smart client and web client development technology in many, many, many years. Now is an extremely exciting time to be a smart client developer, or to rediscover smart client development if you (like me) have been hiding in server-side code over the past decade or so. WebAssembly is the technology that may reshape the way we build client-side software, and it is really cool!

I've been a smart client developer since 1991 when I first started exploring how to build apps on my Amiga and on Windows 3.1. Prior to that point I was purely focused on building minicomputer apps that used VT100 terminals to interact with the user. And I must confess that (after a long and painful learning curve) I completely fell in love with the idea of making full use of the powerful computing devices sitting on my users' desks, and later laps, and these days that they hold in their hands.

But it certainly hasn't been a smooth ride from 1991 to 2018! Our industry tends to engage in wide pendulum-like swings in terms of technology. So I went from terminals to PCs to browsers-as-terminals to mobile to browsers-as-smart-clients to a major resurgence in command line windows (bash and PowerShell) - which brings us to now.

I've noticed over all this time though, that end users prefer a smart, interactive, and responsive experience. They never liked terminals, and I think we all agree that the "classic web" was even worse than using a 3270 or VT terminal for the most part. Yuck!

So while there've been these pendulum swings, the overall gravity of the changes have focused on how to build smart clients that make users happy, while trying to achieve the zero-friction deployment models that make terminals and browsers so popular.

For a brief, shining moment in 2007-2009 we had a vision of what "could be" via Silverlight. Zero friction web deployment to give the user a full-blown smart client experience based on mature and modern developer tooling, including unit testing and all the other goodies we rely on to make quality software.

Sadly Apple and Microsoft managed to derail that technology, leading to us spending a decade on a different approach: single page apps (SPAs). A valiant attempt to use web client technologies (html, css, JavaScript) to build comparable smart client productivity and capabilities to what was created by Visual Basic and PowerBuilder in the 1990's, and then carried through the 00's via .NET with Windows Forms and WPF.

I'm sure there are a lot of lessons to be learned by looking at what's transpired over the past decade in this regard. One conclusion I take from it, is that without some organization devoted strongly to creating all the tooling necessary to build a smart client app development environment, this stuff is nearly impossible.

To be clear, what I'm saying is that Visual Basic went from a toy in 1991 to the dominant way of building apps by 1997. Beyond that, by 1997 it was pure joy to build Windows apps, because the tooling was highly productive, very stable, and we then got to enjoy a stable platform from 1997-2002. Think about that - learn your tools and just be productive for FIVE YEARS!!

Today the typical web development experience using Angular and TypeScript (the dominant players in the space) generally seems to revolve around getting four DAYS of productivity, and then spending a day troubleshooting why the dev pipeline broke because of some npm package that got changed somewhere in the world.

My personal guess as to why web client development remains so fragile is that it is "owned" by hundreds of individuals and companies, all of whom do whatever the f-ck they want, when they want - and we just sit on top of that quivering mass of software and try to build multi-million dollar enterprise apps. Knowing that even if we get them built and deployed, that they'll never be stable without continual work to accommodate the random changes constantly occurring to the underlying muck on which we've built that software.

If you are a consultant who charges by the hour there's no better world in which to live. The money will never stop flowing, and you'll never have to worry about finding work, because at the very least you'll always have a job dealing with these random changes to the dozens or hundreds of JavaScript library dependencies used to build every app.

If you are a business decision maker or leader in IT, you are probably just starting to realize what a nightmare you've stepped into, and will quickly be trying to figure out how to escape the world of web client development. Hopefully with a little dignity, if not your job.

Yeah, I know. At this point some of you are probably thinking that this is how it has always been. You have no memory of building apps with VB6, and then Windows Forms, and then WPF. All platforms that evolve, but don't break on a weekly basis. Believe me though - there really was a time when software could be built, tested, deployed, and then it would actually work for months or even years with little to no maintenance beyond enhancements and other things that provided real business value.

Perhaps I'm just impatient. Maybe the web client world will eventually stabilize and become productive at the level of the technologies we had through the 90's and 00's. Maybe it just takes 20 years instead of 10?

Or maybe we need another vector for innovation.

I think that vector is just now arriving on the scene and I'm very excited!

WebAssembly is now available (or about to be available) in all major browsers. It is now in Firefox, Chrome, and Edge. Safari is lagging, but Apple will get with the modern world very soon.

You know how browsers (used to) run html, css, and JavaScript?

Now they also run web assembly code.

At a very basic level all this means is that JavaScript is no longer the only programming language for the web. And thanks to the Canvas and OpenGL support provided by HTML5, it is true that html/css aren't even the only ways to create the visual elements for end users.

For many years now people have been trying to figure out ways to "escape" JavaScript. Mostly by creating other languages that transpile or even compile into JavaScript. One of the most popular of these is TypeScript, which is a true superset of JavaScript, with a bunch of extremely nice features that transpile into JavaScript before the code is run on the browser. But in all these cases the new language is limited by how it can be converted into JavaScript.

WebAssembly (wasm) offers an alternative. The wasm engine is nestled in the browser right alongside the JavaScript engine, really filling the same niche: running code in the browser. Ultimately this means developers can choose to develop in JavaScript or something that compiles into JavaScript, or they can develop in any other language that can compile to wasm.

Today C, C++, Go, Rust, and probably other languages have wasm compilers. Other languages with compilers and runtimes built using, let's say C, have subsequently been built for WebAssembly too - Python being a good example. The Xamarin team at Microsoft took the open source mono implementation of .NET and built that for WebAssembly, so now .NET (C# and F#) is available in the browser.

My personal background is very Microsoft-focused. But WebAssembly isn't a Microsoft thing. It is a standards-based initiative led by the Mozilla Foundation:

No longer are smart client developers stuck only with JavaScript. We can now escape the JavaScript hegemony and use nearly any other language!

You might still choose to use html/css, but with C or Go or C# instead of JavaScript as your programming language. One example of this is the Blazor project. In many cases you'll probably see performance benefits, because those languages have better compiler optimizations, and because wasm runs faster than JavaScript in most cases. Beyond which, many of these other languages have more robust tooling for development, testing, DevOps, and more.

What is interesting is that other UI technologies now compete with html/css in the browser. Again, the HTML5 Canvas and OpenGL support means that pretty much anything can be rendered in the browser window. As an example, the Ooui project has Xamarin Forms (XAML) running in the browser on top of the mono .NET implementation.

It is this last bit that has some folks on twitter comparing WebAssembly to Microsoft Silverlight from 2007. But that's a very incomplete and misleading comparison.

WebAssembly represents something much bigger and more powerful than Silverlight: the use of many different programming languages and UI frameworks in the browser as alternatives to the previous html/css/JavaScript monoculture. We can now think of the browser as a true client-side target for smart client development on a par with Windows, macOS, Android, and iOS.

The fact that Microsoft and the open source community have been able to get .NET, ASP.NET Razor, and Xamarin Forms running in WebAssembly are merely illustrations of just how powerful wasm is today, and I think are just a teaser for the innovation and exciting stuff we'll see in the future!

And yes, I do think this will directly allow us to recapture the smart client development productivity and stability we enjoyed for a couple decades when building software using VB and .NET.

Saturday, March 24, 2018 4:26:54 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Thursday, March 22, 2018

I am pleased to announce the release of CSLA .NET version 4.7.100 with full support for netstandard 2.0 and .NET Core 2.

The packages are now in NuGet. Once some final updates to the samples are complete and merged into master I'll create a formal release tag/page on GitHub.

This release also includes some other very exciting capabilities, including:

  • #760 Add support for ASP.NET Core 2.0
  • #759 Add support for EF Core (EntityFrameworkCore)
  • #813 Major performance improvement when data binding to large object graphs thanks to keithdv
  • #795 Add Transactional attribute back into netstandard 2.0 code
  • #800 Changes to configuration so it is possible to configure CSLA without any web.config or app.config files (such as in .NET Core, etc.)
  • #496 Support ClaimsPrincipal via new CslaClaimsPrincipal type
  • #729 ApplicationContext now defaults to using AsyncLocal to maintain values on the current thread/context with help from j055 BREAKING CHANGE
  • #712 Support in-place deserialization of an object graph
  • #748 Major improvements to serialization via MobileFormatter thanks to jasonbock
  • #763 Update to samples thanks to tfreitasleal
  • #688 Get ApplicationContext.User authentication working with ASP.NET Core thanks to dazinator
  • #766 Update to use latest UWP libraries for Windows 10 Fall Creators Update BREAKING CHANGE
  • #790 BUG: Fix AmbiguousMatchException in data portal thanks to iherwald
  • #710 BUG: Fix ambiguous Save method issue thanks to rabidkitten

There are a couple known issues with this release:

  • #818 Xamarin projects using System.Data.SqlClient show a warning about this assembly's location
  • #794 UWP projects show warning PRI263: 0xdef01051 messages relative to CSLA resource strings
  • #822 There are two "sets" of CSLA packages/assemblies: one for full .NET 4.6.1+ and one for netstandard (including Xamarin, UWP, .NET Core, etc.) due to a type error between netstandard and full .NET
  • #703 Though netstandard supports BinaryFormatter, that is currently not an option from the CSLA configuration, and this needs to be addressed

Regarding the NuGet/assembly split noted in #822:

Right now there are two "families" of CSLA .NET packages in NuGet. One that supports full .NET and one that supports all other runtimes.

The full .NET family must be used for the following types of app:

  • Windows Forms
  • WPF
  • ASP.NET (other than Core)
  • Console apps (other than Core)
  • Azure Functions
  • Any other runtime hosted by full .NET 4.6.1+

The netstandard family must be used for the following types of app:

  • Xamrin
  • UWP
  • .NET Core
  • ASP.NET Core
  • Any other runtime not hosted by full .NET 4.6.1+

What this means for you is that if your n-tier app is 100% full .NET or full netstandard then you can live within one of those families. BUT if your server is full .NET and your client is Xamarin (for example) then your business library assemblies need to be compiled twice: once for full .NET and once for netstandard.

The Samples\ProjectTracker app shows how this is done by using a Shared Project to contain the code, and two concrete class library projects that compile the code for full .NET and netstandard respectively.

Thursday, March 22, 2018 1:38:26 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Thursday, March 15, 2018

There's some really wonderful work happening now that mono runs in webassembly. There's the Blazor project, and perhaps more exciting is an initiative that has Xamarin Forms running in webassembly.

Blazor sits on mono in webassembly and provides a Razor style UI framework. You write your .NET (C#) code to run behind an html/css UI created using Razor syntax.

Frank A. Krueger just published a different approach, where Xamarin Forms runs in the browser via webassembly, so your Xamarin Forms app (XAML + C#) runs on the client inside the browser. If you follow the above link, you'll find a nice walkthrough on how to use the dotnet command line to create a simple project and run it in a browser.

I started there, and thought it would be fun to try a more robust Xamarin Forms project using Visual Studio, XAML and code-behind. Pretty much my standard approach when building apps for iOS or Android.

Here are my steps (and the code is in GitHub as XFOouiDemo):

  1. Run through Frank's walkthrough - in my case on Ubuntu in Windows 10 WSL (Windows Subsystem for Linux), where I have dotnet installed, and of course Linux already has python - the result is that you should have XF running in your browser with a simple button that counts clicks
  2. Put the walkthrough directory on /mnt/c somewhere so the files are available to Windows as well as Linux - my path is /mnt/c/src, which is c:\src on the Windows side
  3. Open the csproj file in Visual Studio
  4. Add a NuGet reference to Xamarin.Forms (at this point you won't be able to do a dotnet build on Linux because XF apparently doesn't yet work correctly with .NET Core)
  5. Build the project - or maybe just restore NuGet packages
  6. Close and re-open VS (I found this stabilized things a lot)
  7. Add a new item to the project - specifically a Xamarin Forms ContentPage
  8. Edit the xaml to show your content, or not, as you choose
  9. Edit the Program.cs file as shown below
  10. Build the project in Visual Studio
  11. Switch back to your WSL window and run python to rehost your new code
  12. Again navigate to http://localhost:8000 in your browser to load your updated app, and you should see your new XAML-based content

The updated program.cs file is this:

using System;
using Ooui;
using Xamarin.Forms;

namespace MyFormsApp
  class Program
    static void Main(string[] args)
      // Initialize Xamarin.Forms

      // Create the UI
      var page = new Page1();

      // Publish a root element to be displayed
      UI.Publish("/", page.GetOouiElement());

Basically just replace all the manual creation of controls with an instance of your XAML page (in my case Page1.xaml).

What might bend your brain a little here, is that it might appear that I'm compiling the code on Windows and running it on Linux. But that is not what's happening. Remember that the code is running in your browser, not on Windows OR on Linux. So it doesn't matter whether you compile on Linux or Windows, the output of the compilation is wasm code that's downloaded to the browser where it is executed.

Thursday, March 15, 2018 6:58:04 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Monday, December 18, 2017

A couple years ago I left the Windows phone ecosystem. It was a hard thing to do, because Windows 10 on the phone is pretty wonderful, but the lack of apps made the platform undesirable.

In the end I switched to the iPhone 6s, after trying Android and being dissatisfied at the time.

About a week ago I switched to Android. The price tag on the iPhone X, coupled with ongoing frustrations with iOS and the lack of control made me give Android another try. And the fact that a lot of people told me that Android has improved a lot over the past couple years.

My new phone is a OnePlus 5T, and I'm on AT&T.

After about 10 days with the new phone I wanted to capture my initial thoughts, before they fade.


  • Cortana is my default assistant - oh the relief - Siri remains like Cortana's dumber older cousin, and it is really really nice to be back where I have a good assistant!
  • The Microsoft apps (Office, Outlook, OneDrive, launcher, lock screen, Cortana, etc.) all play together so well on Android because they aren't trying to work around Apple's silly rules - the experience is more pleasant and integrated.
  • All the apps I used on the iPhone are here on Android, so I lost no functionality by switching platforms.
  • I can use Waze as my default navigation app finally - this makes me so very happy!
  • The screen and performance and memory and battery life and charge speed of the OnePlus 5T are all excellent - a big step up from my iPhone.


  • Bluetooth doesn't work "right" between Waze (or Cortana) and my Ford Sync system (specifically my Sync system has to be listening to the BT stereo device to get any audio from Waze or Cortana, so I can't use Waze and listen to Sirius Octane - arg!!) This was not a problem on Windows or iOS.
  • Activity badges on app icons are far from reliable Not a problem with Windows live tiles or iOS.
  • Some apps on Android are still not as good as their iPhone equivalents; iPhone is clearly the highest priority, followed by Android and so Android users are sometimes second class citizens.
  • Contact management sucks on Android, just like on the iPhone. Nobody has figured out how to make contacts work seamlessly from Office 365, Google, and (well, except for Windows Phone 7, which nailed it - but then even Microsoft messed it up with Windows 10).

For me the pros have already outweighed the cons. The Bluetooth behavior is a serious pain though, almost enough to offset the pros - how do Android people live with this crappy BT experience????

But as I say, the pros - Cortana as default assistant and the smooth integration of all the Microsoft launcher, lock screen, and apps make Android the superior experience.

Cortana is a big thing for me. I limped by with Cortana on the iPhone, but the experience is much superior on Android. And I use Cortana on my Surface and desktop. And I have a HK Invoke, so I have Cortana in my home as well (so she can do all my home automation and play music mostly).

I've had people ask if it was hard to leave the Apple ecosystem. But I wasn't in the Apple ecosystem, I consciously chose to stay in the Microsoft ecosystem while using my iPhone, because I didn't want the vendor lock-in from Apple.

You might laugh at that, because I'm arguably locked in to Microsoft. But Microsoft has no "horse in the race" with mobile, so their ecosystem is the one place you can go to remain neutral between Apple and Google, and that's a powerful benefit.

My OnePlus 5T is a flagship level phone for half the price of Samsung's flagship or an iPhone X.

Avoiding vendor lock-in isn't a goal in and of itself (though people often think it is). The goal is to be able to switch to the best value hardware or OS or platform with minimal penalty because you aren't locked into some vendor's world.

Having switched from one major mobile platform to the other, with virtually no pain, I now feel very comfortable saying that the way to avoid lock-in from Apple or Google is to live in the Microsoft ecosystem 😃

Monday, December 18, 2017 11:38:41 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, November 29, 2017

A while ago I got an Amazon Echo - the little hockey puck one. But I haven't been real pleased, for three primary reasons.

  1. It usually requires me to ask it the same thing twice
  2. It frequently gets disconnected from my network
  3. I'm a heavy Cortana user, and very few of the third party services supported by Cortana are also supported by Echo (no OpenTable, Wunderlist, cross-platform reminders, etc.)

So I took advantage of the recent holiday sales and ordered a Harmon Kardon Invoke, which is a Cortana based device.

As with most consumer devices post-Kindle, the Invoke comes in nice, friendly packaging.

(the pictures are rotated by MarkdownMonster - I don't know how or why, or how to fix it - sorry...)

The device itself feels solid, has some weight, and is attractive.

The swirling light on the top is pretty cool, and the physical ring at the top of the device turns to act as volume. The top of the device itself is touch sensitive, so you can tap it or tap-and-hold to interact. But really, most interaction is by voice.

Setting up the device was easy. When I plugged it in the blue light started swirling, and I used the Cortana app on my iPhone (which I already use all the time anyway) to initialize the Invoke. The whole process was pretty much automated, including connecting to my wifi network. The Invoke updated itself from the Internet once connected

Using Cortana with the Invoke is the same as with my Xbox or Surface. "Hey Cortana" and away you go! All the stuff I can do with Cortana on my iPhone or Surface seems to work the same on the Invoke.

What the Invoke does that seems special (as compared to Cortana via iPhone, Surface, or Xbox) include:

  1. Playing music via Spotify (one step during configuration is to identify your streaming music provider)
  2. Making voice calls to cell phones and land lines (the Invoke includes a year of free calling via Skype)
  3. Interacting with SmartThings based devices (and others too, but I have a ST hub, so that's what I'm using)

Unlike the Echo, Cortana has yet to need me to repeat anything, so that's a bonus right there!

Of course the Invoke sounds way better than the Echo Dot, but that's not a fair comparison. A friend of mine who has a full-sized Echo says that the Invoke sounds better than the Echo. That makes sense, given HK's reputation for audio.

The most important thing for me is that the Invoke, using Cortana, was instantly aware of, and integrated with, my existing reminders, to-do lists, calendars, package tracking, flight tracking, and everything else for which I already use Cortana.

Where really embracing the Amazon Echo would require me to use a whole other ecosystem, the Invoke just gave me access to the ecosystem I'm already using.

There's no question that the Echo has access to a lot more apps than Cortana. But it doesn't give me access to the apps I'm already using, and I guess that's the really thing for me - I don't want to migrate to a whole new to-do list app, stop using Foursquare and Yelp and OpenTable. I like those apps and services, and I'm used to them, and with Cortana I get to keep using them.

Wednesday, November 29, 2017 3:17:52 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, November 7, 2017

When I worked in bio-medical manufacturing batch processing was a core element of our overall IT strategy. Not on the mainframe, but on the VAX.

The OpenVMS operating system, combined with VAX Clusters, had an amazingly powerful and flexible batch processing model, on top of which I wrote a relatively sophisticated scheduling engine to manage our nightly, month-end, and year-end batch processing.

We'd run dozens of batch processes each night, and many more for month/year-end. There were dependencies, and some jobs could or couldn't run in parallel with other jobs. My scheduler managed all that automatically, allowing users to add/remove requests for processing jobs and ensuing they fit into the schedule appropriately.

That basic robust batch processing capability is something I've missed ever since coming to Windows (so for 20+ years now), and I'm really thrilled to see the feature available as a first-class offering in Azure.

The fact that Azure also provides low-priority/lower-cost batch hosts is a nice bonus.

Now people are going to have to dig back in their memories, or start from scratch, and learn how to fully leverage batch processing once again!

Tuesday, November 7, 2017 2:55:47 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, October 10, 2017

The CSLA framework is now officially 20 years old. Seriously, some version of CSLA has been out in the world for people to freely use since 1997 when my Professional VB5 Business Objects book came out with the code on a disc attached inside the back cover.

Although I didn't technically call it "open source" back then, because the more common terms were "freeware" and "shareware", and I considered CSLA to be "freeware". Those terms eventually became subsumed by what we now know as Open Source Software (OSS), and of course that's the term I use today.

I'm proud of the fact that I've been contributing to the OSS world for 20 years. Not too many open source projects last this long.

And more importantly, I'm humbled and amazed by the emails and feedback I've received over the years - both in terms of people using CSLA, and also people who've benefited from reading my books. And of course by the amazing contributions by colleagues and community members, several of whom I'll call out later in this article.

The following is a pretty long post, but I thought that it would be good to record the highlights of the past 20 years.

Why Open Source?

Lots of people have opinions and views and motivations about why they use and/or contribute to open source.

Personally, my motivation to contribute flows from being an early user of the concept. I very much believe that my career wouldn't have gone where it did, except for me having access to freeware, shareware, and open source software.

Back in 1989 (give or take) I was making my living being a DEC VAX programmer. And 1-2 times each year we'd get a couple big magnetic tapes (like in those very old movies) that contained tons and tons of freeware, shareware, and early open source (GNU and copyleft) stuff. I'd typically come in on a Saturday, download the index from the tapes and then selectively download and play with various tools.

Things like awk (really gawk) that I used to transform how our company processed reporting data. Or like uupc, which was a UseNet protocol implementation for the VAX that allowed us to get store-and-forward email service to the world over our 1200 baud modems.

I looked like a frickin' rockstar thanks to those tools!

Similarly, at the time, I was an Amiga fanatic. And the Fred Fish collection of software was like a lifeline to all that was cool and fun in the world of ... everything!

Yes, like everyone I've needed to make a living, support my family, save for the kids college and my retirement. But, and I know this sounds sappy, having built my career on the shoulders of some impressive people's contributions, I was on the lookout for a way to try and do the same for others.

CSLA COM or "Classic"

CSLA started out as the "Component-based, Scalable, Logical Architecture" in the world of COM. And I didn't originally intend for it to be a standalone framework. My original thought was that this code was an example of what people could do, and it fit into the bigger narrative of my book.

By the time I wrote the Professional VB6 Business Objects and Professional VB6 Distributed Objects books though, it was already becoming clear that I was mistaken. I phrase it that way on purpose, because by that time I was receiving emails with bug reports, feature suggestions, and other comments - where people were clearly taking the code and using it as a framework, not as an example.

Want to see that old code (and a picture of me from 20 years ago)? I put the old VB6 CSLA code in a GitHub repo for safe keeping.

Kevin Ford and I worked together on a project in 1996-97, and the two of us argued extensively about how things should work. Without his input, CSLA would not have been what it was, and Kevin has been providing input and contributions from then through today.


Toward the end of the 1990's I was seriously considering switching to the shiny new Java world. Primarily because I'd become increasingly frustrated with COM and DCOM, and yearned for the more object-oriented aspects of Java. Fortunately for me, I became aware of things like a new "COOL" language, and "COM+3". Technologies that ultimately became what we know as the .NET framework, VB.NET, and C#. So I stuck with the Microsoft world through that time.

Working with the earliest pre-releases of .NET I tried directly porting the COM code to .NET. That sort of worked, but clearly wasn't what I wanted, because it didn't leverage the new OO features available to me. I believe I wrote and rewrote the core of CSLA three different times into .NET, each time learning more and more about how .NET worked and what I could do with it.

The end result was CSLA .NET 1.0. Still very much a bare bones "framework" that I still personally considered as much an example of what to do as a framework someone could use out of the box. But by that point I had reconciled myself to the reality that people would be using it as-is, so I use XML comments and a short-lived, but very good, OSS tool called ndoc to create a help file for the framework.

And of course CSLA .NET came out concurrent with my Professional VB.NET Business Objects book. That was republished not long after under the title Expert One-On-One Visual Basic .NET Business Objects because my books were purchased from Wrox Press by APress. Not that this affected CSLA .NET, but it obviously affected me and my books - in a positive way, as APress was great to work with!

CSLA .NET 1.1 and C#

In fact, I wrote the Expert C# Business Objects book with APress. The port of CSLA .NET from VB.NET to C# was almost entirely done by a colleague of mine: Brant Estes. And I think he did it in just a few days - amazing work by an amazing developer!

Thus started the era of maintaining the "same codebase" twice in two different languages. You can see it in the v1-5-x branch - two versions of everything.

This is also about the time that the term "CSLA" stopped being an acronym and became just an unpronounceable word. The acronym no longer applied really, because .NET is object-oriented, not component-based. What I should have done is given it a cool name instead of some letters. Saying "see es el ay" is tedious. People were saying "the Lhotka framework", or "the coleslaw framework", or the "cuz law framework". But I didn't have that foresight, and after 20 years I doubt I'll change the branding now.

So now we're in 2002-2003, give or take, and the Internet as we know it today was really coming together, including the idea that OSS projects should have public source repos. So I set up a Subversion (svn) server and a web site with downloadable zip archives containing the code and samples. I still figured people should leverage the code, not the framework as a "product".


That changed in 2005 with CSLA .NET 2.0, which primarily supported .NET 2.0 and generics. And of course the new Expert C# 2005 Business Objects and Expert VB 2005 Business Objects books. But somewhere around this time is when I started releasing not just the code, but also pre-compiled binaries for people to leverage.


In 2007 Microsoft released .NET 3.0, including WPF, WCF, and WF. Supporting WCF meant decoupling the data portal from .NET Remoting, so people could use Remoting, asmx, or WCF as a transport protocol. Supporting WPF meant lots of alterations to data binding code, because WPF interacts with the data binding interfaces differently from Windows Forms. Very messy and hard to accommodate, so this was the point in the evolution of CSLA where I realized the primary benefit was how it mitigates all the differences in data binding, not the data portal.

Around this time was my first foray into self-publishing content via the web, with my CSLA .NET 2.1 Handbook and Using CSLA .NET 3.0 ebooks. Both published in VB and C# editions.

CSLA .NET 3.7 and Silverlight

2008 brought Silverlight 2, the first time .NET fragmented into two totally different platforms. Getting CSLA decoupled from full .NET, such that it could also support the Silverlight flavor of .NET, was a major undertaking. Thankfully CSLA had Magenic as a patron, and Magenic committed several full time developers for a period of months to work through all the issues necessary for CSLA to run on both full .NET and Silverlight.

2008 is also the year I published my last paper books: Expert C# 2008 Business Objects and Expert VB 2008 Business Objects. By this time I'd switched entirely to C# myself, and a colleague named Joe Fallon was responsible for getting the VB code and book out there.

Subsequent to 2008 the VB source code for the framework itself was dropped, and only the C# framework code continued forward. Obviously the framework supports all .NET languages, so it can be used by VB or C#, but the framework code itself is C# only from 2008 forward.

Justin Chase was instrumental in the port to Silverlight. In fact, there were no good ways to run unit tests in Silverlight, especially if you wanted the same tests to run in .NET. So Justin created UnitDriven to solve that problem.

Marimer LLC

In 2009 I created Marimer LLC as an official company to own CSLA .NET and all related code, content, and business operations. Prior to that point I'd been operating as what's called a Sole Proprietor, and having an LLC provides a level of legal protection. Not that I've ever needed that, thankfully.

The trigger for this was a very large company who wanted to use CSLA .NET, but even though it was open source they didn't want to use a product that didn't have a company behind it. Other people were covering the legal costs to create the LLC and ultimately it was to my benefit, so I saw no downside.


A couple years later, in 2010, came some of the biggest changes to CSLA .NET since the addition of generics.

This is also the point where I switched completely to self-published books and videos via the web with the Using CSLA 4 ebook.

The has been online with that content for seven years now. Wow!

The massive work to decouple from .NET and support Silverlight was far more work than what we did in .NET 4, but it was largely transparent to users of CSLA .NET (which is kind of the point after all). But the changes we made to CSLA .NET 4 were breaking changes for users of the framework.

I say we, because by this point in time CSLA had accumulated quite a number of contributors. A list of contributors since we switched to GitHub is on the CSLA .NET contributors page. I'm truly sorry I have no way to list all the people who contributed to the svn codebase, though the CSLA .NET Open Hub page has captured quite a lot of historical data and says 61 people have contributed.

But back to CSLA .NET 4 and the big changes. What did did in this version was add the basis for a robust rules engine. This was based on lots of community feedback from our early attempts with a rules engine starting in version 3.8 and the influence of David West through his Object Thinking book.

Building on this rules engine, Jonny Bekkum has evolved the engine substantially over the past several years, and today it is able to handle extremely complex scenarios. Best of all, the engine retains its relative simplicity for less complex scenarios and rules.

Beyond that, Jonny has been a major contributor to other parts of the framework, one of my most trusted advisors, and a stalwart member of the broader community over many, many years.

I also want to call out Tiago Freitas Leal, who's run a parallel OSS project called CslaCodeGenFork, has worked closely with Jonny to manage the community-based CslaContrib project, and has been an active contributor to the CSLA framework and the community. Tiago has been involved for almost as many years as Jonny.

This is also about the time that Jaans helped create the initial NuGet definitions necessary to get CSLA into NuGet. Most of his nuspec files remain intact, though perhaps evolved slightly over time.

Enter mono, mono for Android, and Windows Phone

In 2011 the open source mono port of .NET became much more relevant to me than it had been prior to that point. Primarily because the mono project embraced Android and iOS as well as Linux.

Jonny Bekkum leveraged the decoupling of CSLA .NET from full .NET to get a version running on mono, and based on that I tried to get it working on Android and iOS. Android was successful, but technical limitations of mono on iOS blocked our progress at that time.

We also leveraged the decoupling from full .NET in order to get a version of CSLA running on the nascent Windows Phone platform.

Turns out that all that work back in 2007 to support Silverlight was incredibly valuable going forward, even though Silverlight itself ultimately had no future. Because CSLA .NET had been largely decoupled from full .NET though, we've been able to get CSLA .NET running on over 11 different flavors/versions of .NET simultaneously - all from a single codebase!


In 2012 Micrsoft came out with the ill-fated Windows 8, and what I personally describe as the evolution of Silverlight: WinRT. Porting CSLA .NET to WinRT took some effort, mostly because Microsoft messed around with the way the .NET reflection API worked. Why they changed one of the fundamental building blocks of .NET itself is beyond me, and it caused a great deal of pain. But we worked through it.

The other big impact was that the XAML supported by WinRT was comparable to that from Silverlight 2. Which is to say it was pretty limited compared to WPF or Silverlight 5. Fortunately I was able to dust off a lot of old Silverlight 2 XAML code and use it to support WinRT. This goes to show the value of having good source control history over a period of years!

I think this is also about the time that we switched the source code repository from svn to git, and the server from my personal server to GitHub. Bringing all the svn history forward was not trivial. At all. It was my colleague Nermin Dibek who convinced me to switch to git, and Nick Schonning suffered through the pains necessary to convert the svn history into git so it was (mostly) preserved.

Enter Xamarin

By 2013 that mono for Android and iOS initiative had been canceled by its patron/owner Novell. Fortunately the project remained alive via a new company named Xamarin. Better still, Xamarin overcame some of the earlier iOS limitations, and so CSLA .NET was able to provide full support for Android and iOS via Xamarin.

From a historical perspective, it is also worth noting that this is about the time that, thanks to the confusion around the iPad and Windows 8, enterprises generally decided to stop building smart client apps at all, favoring to focus on HTML5 web apps and the newly coined "single page app" concept.

So supporting Xamarin was important from my viewpoint, because it felt like people might never again write a .NET client-side app otherwise. Today I'm not so pessimistic, primarily because today Xamarin is owned by Microsoft and supports cross-platform development across Windows 7, 8, 10, iOS, Android, Linux, MacOS, and more. Damned impressive!

Windows 10

In 2015 Microsoft released Windows 10 to replace Windows 8. Now Windows 8 was largely a commercial failure, but I believe it did one very important thing: it broke everyone's conception about what Windows looked like and how it worked.

Windows 10 brought back many of the best-loved features of Windows 7, while keeping and refining the bits of Windows 8 that were actually good. Personally I really enjoy Windows 10, more than I did Windows 7 (which I thought at the time was the best Windows ever).

Windows 10 brought with it an evolution of WinRT called UWP, or the Universal Windows Platform. UWP had an interesting quirk, in that it ran on a super-early implementation of yet another flavor of .NET: .NET Core. Getting CSLA .NET to run on this new UWP flavor of .NET wasn't too hard, primarily because it really is just an evolution of WinRT, which we already supported.

Support for UWP means that CSLA .NET supports native Windows 10 development, and also works for Xbox and Hololens development. I think that's pretty cool!

.NET Analyzers

Jason Bock has been a colleague and friend for many years, and his passion for compilers and low-level implementation details around .NET is hard to match. In 2015 Microsoft introduced this idea of .NET analyzers, which allow us to write components that runs within the .NET compilers and analyzes our code as we write and compile it.

Jason wrote a bunch of analyzers for CSLA .NET that help enforce the guidelines people should follow when using the framework. Prior to this point those guidelines were documented in my books and code samples, but there was nothing to help remind people what to do as they were coding. Jason's analyzers changed that entirely, providing real-time feedback and code refactorings directly within Visual Studio. Awesome!

MIT License

From the inception of CSLA until 2016 I'd been using a custom license based largely off the Apache license. And that never really caused any issue, but it did occasionally result in me having an email exchange with an organization's lawyer as they approved the license.

Switching to the MIT license is something, in retrospect, that I should have done much earlier. Now I don't get any such email exchanges, because everyone knows and understands the MIT license.

That's perhaps one of the lessons to learn here. I started doing all this back before "open source" was as formal or defined as it is today. And "little" things like licensing rarely get updated over time, because the focus is always on the code and other fun stuff. It is probably a good idea to review things like licensing more frequently over the lifetime of a project, just to make sure those elements remain up to date and relevant as times change.

.NET Core and NetStandard

The most recent changes to the .NET world have largely centered around the new .NET Core implementation of .NET, a version of .NET than is truly cross-platform. And something called netstandard, which is an API definition against which we can write code, and have that same compiled code work on multiple flavors of .NET.

CSLA .NET 4.7 supports netstandard 2.0, and that means a single Csla.dll works on all the platforms that conform to netstandard 2.0, including:

  • Full .NET 4.6.1+
  • Xamarin Android, iOS, and more
  • UWP starting in October 2017
  • .NET Core 2.0

Basically all the modern versions/flavors of .NET now support netstandard 2.0. And so does CSLA .NET 4.7.

So where we've been compiling the CSLA source code 11+ times - once for each flavor of .NET that's running out there, the future looks bright, in that hopefully, eventually, we'll be able to build it just one time.

Of course it'll be a while before that happens. Today CSLA still supports people as far back as .NET 4.0. But the future is bright, and today's messy reality of various versions/flavors of .NET and PCLs and everything else is clearly going to be replaced by netstandard.

Thank you

It has been a pretty incredible 20 years. I've met people (virtually and IRL) from all corners of the globe, and I've become good friends with many folks.

I've been able to continually improve and maintain the CSLA framework through the revenue generated by my books, training videos, and by having Magenic as a patron. Even with all that though, none of this would have been possible without the fantastic support from many thousands of people who've read my books and used CSLA, and the hundreds of people who've participated in the CSLA forums over the years, and the scores of people who've directly contributed to the CSLA framework and related projects.

As I wrote this article, I called out the names of a few people who've helped shape and create CSLA and the community. But there are other people in our small community that were and are also part of the narrative. Please know that I value each and every one of you as a colleague and friend.

Closer to home, the steadfast support from my wife and kids and close friends - really I don't have the words to express my gratitude and love for all of you. Much of my early work on CSLA and the books was done with my sons bouncing on my knees, sleeping in my lap as I typed, or making sure I got outside occasionally for some sunshine. And believe it or not, my wife and I are almost going to celebrate our 30th anniversary. So even with me disappearing to write for extended periods of time, we're still together and enjoying life.

CSLA .NET Futures

Where to from here?

I'm more optimistic about the future of .NET than I have been for many years.

.NET on the server is gaining new life and enthusiasm thanks to .NET Core and the ability to run your code on Windows, Linux, MacOS, in Docker containers, and I'm sure more to come.

.NET on the client might be on the rebound. I think as more people discover just how horrific Electron is as a development platform for desktops, and they are already backing off from Cordova on mobile, this will open the door for Xamarin and .NET to be viewed as a desirable alternative. You know, a technology that doesn't suck down memory and CPU for no good reason, and a technology that truly allows developers to leverage each device and platform when needed.

And then there's the great hope, which is web assembly (wasm). If this project continues to progress, and I think it will, browsers will no longer be a homogeneous runtime for JavaScript. They'll be much closer to a true operating system or runtime, supporting many languages, include C# and .NET. Just imagine going to a "web page" and having it run .NET code instead of JavaScript!

And where .NET goes, CSLA .NET goes too.

Tuesday, October 10, 2017 12:36:47 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
On this page....
Feed your aggregator (RSS 2.0)
April, 2019 (2)
January, 2019 (1)
December, 2018 (1)
November, 2018 (1)
October, 2018 (1)
September, 2018 (3)
August, 2018 (3)
June, 2018 (4)
May, 2018 (1)
April, 2018 (3)
March, 2018 (4)
December, 2017 (1)
November, 2017 (2)
October, 2017 (1)
September, 2017 (3)
August, 2017 (1)
July, 2017 (1)
June, 2017 (1)
May, 2017 (1)
April, 2017 (2)
March, 2017 (1)
February, 2017 (2)
January, 2017 (2)
December, 2016 (5)
November, 2016 (2)
August, 2016 (4)
July, 2016 (2)
June, 2016 (4)
May, 2016 (3)
April, 2016 (4)
March, 2016 (1)
February, 2016 (7)
January, 2016 (4)
December, 2015 (4)
November, 2015 (2)
October, 2015 (2)
September, 2015 (3)
August, 2015 (3)
July, 2015 (2)
June, 2015 (2)
May, 2015 (1)
February, 2015 (1)
January, 2015 (1)
October, 2014 (1)
August, 2014 (2)
July, 2014 (3)
June, 2014 (4)
May, 2014 (2)
April, 2014 (6)
March, 2014 (4)
February, 2014 (4)
January, 2014 (2)
December, 2013 (3)
October, 2013 (3)
August, 2013 (5)
July, 2013 (2)
May, 2013 (3)
April, 2013 (2)
March, 2013 (3)
February, 2013 (7)
January, 2013 (4)
December, 2012 (3)
November, 2012 (3)
October, 2012 (7)
September, 2012 (1)
August, 2012 (4)
July, 2012 (3)
June, 2012 (5)
May, 2012 (4)
April, 2012 (6)
March, 2012 (10)
February, 2012 (2)
January, 2012 (2)
December, 2011 (4)
November, 2011 (6)
October, 2011 (14)
September, 2011 (5)
August, 2011 (3)
June, 2011 (2)
May, 2011 (1)
April, 2011 (3)
March, 2011 (6)
February, 2011 (3)
January, 2011 (6)
December, 2010 (3)
November, 2010 (8)
October, 2010 (6)
September, 2010 (6)
August, 2010 (7)
July, 2010 (8)
June, 2010 (6)
May, 2010 (8)
April, 2010 (13)
March, 2010 (7)
February, 2010 (5)
January, 2010 (9)
December, 2009 (6)
November, 2009 (8)
October, 2009 (11)
September, 2009 (5)
August, 2009 (5)
July, 2009 (10)
June, 2009 (5)
May, 2009 (7)
April, 2009 (7)
March, 2009 (11)
February, 2009 (6)
January, 2009 (9)
December, 2008 (5)
November, 2008 (4)
October, 2008 (7)
September, 2008 (8)
August, 2008 (11)
July, 2008 (11)
June, 2008 (10)
May, 2008 (6)
April, 2008 (8)
March, 2008 (9)
February, 2008 (6)
January, 2008 (6)
December, 2007 (6)
November, 2007 (9)
October, 2007 (7)
September, 2007 (5)
August, 2007 (8)
July, 2007 (6)
June, 2007 (8)
May, 2007 (7)
April, 2007 (9)
March, 2007 (8)
February, 2007 (5)
January, 2007 (9)
December, 2006 (4)
November, 2006 (3)
October, 2006 (4)
September, 2006 (9)
August, 2006 (4)
July, 2006 (9)
June, 2006 (4)
May, 2006 (10)
April, 2006 (4)
March, 2006 (11)
February, 2006 (3)
January, 2006 (13)
December, 2005 (6)
November, 2005 (7)
October, 2005 (4)
September, 2005 (9)
August, 2005 (6)
July, 2005 (7)
June, 2005 (5)
May, 2005 (4)
April, 2005 (7)
March, 2005 (16)
February, 2005 (17)
January, 2005 (17)
December, 2004 (13)
November, 2004 (7)
October, 2004 (14)
September, 2004 (11)
August, 2004 (7)
July, 2004 (3)
June, 2004 (6)
May, 2004 (3)
April, 2004 (2)
March, 2004 (1)
February, 2004 (5)

Powered by: newtelligence dasBlog 2.0.7226.0

The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2019, Marimer LLC

Send mail to the author(s) E-mail

Sign In