Rockford Lhotka

 Tuesday, June 5, 2018

Hello all!

I'm coordinating a codeathon on Saturday, June 23, to work on the Mobile Kids Id Kit app.

This project is sponsored by the Humanitarian Toolbox and Missing Children Minnesota, and provides you with a literal opportunity to make the world a better place for children and parents.

The app is partially complete, and has been created with Xamarin Forms. There are a number of important backlog items remaining to be completed, and we need to do the work to get the apps into the Apple, Google, and Microsoft stores.

If you are looking for a way to use your Xamarin (or ASP.NET Core) skills to make the world a better place, this is your chance! Sign up here.

Tuesday, June 5, 2018 3:45:52 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Monday, May 14, 2018

At Build 2018 Satya Nadella announced a new "AI for Accessibility" program. Having had a few days since then, I have a couple ways I think about this.

One is personal. A little over 2 years ago I had major surgery, including about 15% chance of being partially paralyzed as a result. Fortunately the surgery went well and paralysis didn’t happen, but it got me thinking about the importance of technology and software as an equalizer in life. Something like partial paralysis often ends people’s lives as they know it. With technology though, there’s the very real possibility of people with severe medical conditions living life at a level they never could without those technologies.

The other way I think about this is from the perspective of Magenic. We build custom software for our clients. Sometimes that software is fairly run-of-the-mill business software. Sometimes it is part of a solution that has direct impact on making people’s lives better, in big or small ways. When you get to work on a project that makes people’s lives better, that’s amazingly rewarding!

Every time I’ve had the opportunity to talk to Satya I’ve been impressed by his thoughtfulness and candor. As a result, when I hear him talk about ethical and responsible computing and AI, I believe he’s sincerely committed to that goal. And I very much appreciate that perspective on his part.

Again, veering a bit into my personal life, I read a lot of science fiction, speculative fiction, and cyberpunk. A great deal of that literature deals with the impacts of unfettered technology and AI; consequences both miraculous and terrifying. I also don’t dismiss the (non-fiction) concept of a potential “singularity”, where technology (via transhumanism or AI) results in a whole new class of being that is beyond simple humanity. Yeah, I know, I might have gone off the deep end there, but I think there’s a very real probability that augmented humans and/or AI will transform the world in ways we can’t currently comprehend.

Assuming any of this comes to pass, we can’t understate the need to approach AI and human augmentation in an ethical and thoughtful manner. Our goal must be to improve the state of mankind through the application of these technologies.

The fact that Microsoft is publicly having these conversations, and is putting money behind their words, is an important step in the right direction.

Monday, May 14, 2018 9:23:38 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, April 20, 2018

On Saturday April 21, 2018 I'm giving a talk at TCCC about WebAssembly (my current favorite topic).

Friday, April 20, 2018 3:14:44 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Sunday, April 8, 2018


As you've probably noticed from my recent blogging, I'm very excited about the potential of WebAssembly, Blazor, and Ooui. A not-insignificant part of my enthusiasm is because the CSLA .NET value proposition is best when a true smart client is involved, and these technologies offer a compelling story about having rich smart client code running on Windows, Mac, Linux, and every other platform via the browser.

This weekend I decided to see if I could get CSLA running in Blazor. I'm pleased to say that the experiment has been a success!

You can see my log of experiences and how to get the code working via this GitHub issue:


At first glance it would appear that CSLA should already "just work" because you can reference a netstandard 2.0 assembly from Blazor, and the CSLA-Core-NS NuGet package is netstandard 2.0. However, it is important to remember that Blazor is experimental, and it is running on an experimental implementation of mono for wasm. So not everything quite works as one might hope. In particular, I ran into some issues:

  1. System.Linq.Expressions is unavailable in Blazor, which is how CSLA (and Newtonsoft.Json) avoid use of reflection in many cases (
  2. The DataContractSerializer doesn't work "out of the box" in Blazor (
  3. The Blazor solution template for a .NET Core host with Blazor client doesn't work if you reference one version of Csla.dll on the server, and a different version of Csla.dll on the client - so you have to use the same Csla.dll in both projects (
  4. The HttpClient type isn't fully implemented in mono-wasm, and it only supports passing string data, not a byte array
  5. You can't just create an instance of HttpClient, you need to use the instance provided via injection into each Blazor page

To address these issues I've created a new Csla.Wasm project that builds Csla.dll specifically to work in Blazor.

Issue 1 wasn't so bad, because CSLA used to use reflection on some platforms where System.Linq.Expressions wasn't available. I was able to use compiler directives to use that older code for Csla.Wasm, thus eliminating any use of Linq. There's a performance hit of course, but the upside is that things work at all!

Issue 2 was a bit more complex. It turns out there is a workaround to get the DCS working in Blazor (see issue 511), but before learning about that I used Newtonsoft.Json as a workaround. Fortunately this only impacts the MobileList type in CSLA.

Now keep in mind that Newtonsoft.Json doesn't universally work in Blazor either, because when it serializes complex types it also uses System.Linq.Expressions and thus fails. But it is capable of serializing primitive types such as a List<string>, and that's exactly the behavior I required.

Issue 3 is kind of a PITA, but for an experiment I'm ok with referencing the wasm implementation of Csla.dll on the server. Sure, it uses reflection instead of Linq, but this is an experiment and I'll live with a small performance hit. Remember that the wasm version of Csla.dll targets netstandard 2.0, so it can run nearly anywhere - just with the minor changes needed to make it work on mono-wasm.

Issue 4 required tweaking the data portal slightly. Well, the right answer is to create a new proxy/host channel for the data portal, but for this experiment I directly tweaked the HttpProxy type in CSLA - and that'll need to be corrected at some point. Really no change to the actual data portal should be required at all.

Issue 5 required tweaking the CSLA HttpProxy type to make it possible for the UI code to provide the data portal with an instance of the HttpClient object to use. This isn't a bad change overall, because I could see how this would be useful in other scenarios as well.

The BlazorExample project

The end result is a working Blazor sample, and you can see the code here:

This solution is mostly the Microsoft template.

  • BlazorExample.Client is the Blazor client app that runs in the browser
  • BlazorExample.Server is an ASP.NET Core app running on the server, from which the client app is deployed, and it also hosts the CSLA data portal endpoint
  • BlazorExample.Shared is a netstandard 2.0 class library referenced by both client and server, so any code here is available to both

Code shared by client and server

In BlazorExample.Shared you'll find a Person class - just a simple CSLA business domain class:

using System;
using System.Collections.Generic;
using System.Text;
using Csla;

namespace BlazorExample.Shared
  public class Person : BusinessBase<Person>
    public static readonly PropertyInfo<string> NameProperty = RegisterProperty<string>(c => c.Name);
    public string Name
      get { return GetProperty(NameProperty); }
      set { SetProperty(NameProperty, value); }

    private static int _count;

    private void DataPortal_Fetch(string name)
      using (BypassPropertyChecks)
        Name = name + _count.ToString();

This type is available to the client and server, enabling the normal CSLA mobile object behaviors via the data portal. Anyone using CSLA over the years should see how this is familiar and makes sense.

Also notice that there's nothing unique about this code, this is exactly what you'd write for Windows Forms, ASP.NET, Xamarin, WPF, UWP, etc. One of the key benefits of CSLA - reuse your business classes across every platform where you can run .NET code.

The Blazor client app

In the client project there's a Program.cs file with the app's startup code. Here's where I configure the data portal and ensure there's a serializable principal object available:

Csla.DataPortal.ProxyTypeName =
Csla.DataPortalClient.HttpProxy.DefaultUrl = 
Csla.ApplicationContext.User = 
  new Csla.Security.UnauthenticatedPrincipal();

This is standard CSLA initialization code that you'll find in nearly any modern app. Same as WPF, UWP, Xamarin, etc.

I chose to do my UI experiments in the Pages/Counter.cshtml page.

The real highlight here, from a CSLA perspective, is the LoadPerson method; a handler for the "Load person" button:

async void LoadPerson()
    // Provide injected HttpClient to data portal proxy
    // Get person object from server
    person = await Csla.DataPortal.FetchAsync<BlazorExample.Shared.Person>("Fred");
    catch (Exception ex)
    errorText = ex.Message + ":: " + ex.ToString();

The unique thing here is where the SetHttpClient method is called to provide the data portal proxy with access to the HttpClient object injected at the top of the page:

@inject HttpClient Http

This particular HttpClient instance has been initialized by Blazor, so it has all the correct settings to talk easily to the deployment web server, which is also where I hosted the data portal endpoint.

The page also makes use of Blazor data binding. In particular, there's a person field available to the Razor code:

BlazorExample.Shared.Person person = new BlazorExample.Shared.Person();

And then in the Razor "html" this is used to display the business object's Name property:

<p>Name: @person.Name</p>

Because the LoadPerson method is async, it is necessary to tell Blazor's data binding to refresh the UI when the data has been retrieved. That call to StateHasChanged at the bottom of the method is what triggers the data binding UI refresh.

The ASP.NET Core web/app server

The server project has a couple unique things.

I had to work around the fact that a byte array can't be passed over the network from Blazor. So there's a modification to the CSLA HttpProxy class (client-side) to pass base64 encoded data to/from the server. For example:

//httpRequest.Content = new ByteArrayContent(serialized);
httpRequest.Content = new StringContent(System.Convert.ToBase64String(serialized));

Then in the server project there's a custom HttpPortalController class, copied from CSLA and also tweaked to work with base64 encoded data. For example:

string requestString;
using (var reader = new StreamReader(requestStream))
  requestString = await reader.ReadToEndAsync();
var requestArray = System.Convert.FromBase64String(requestString);
var requestBuffer = new MemoryStream(requestArray);

This controller is then exposed as an API endpoint via the DataPortalController class in the Controllers folder:

using Microsoft.AspNetCore.Mvc;

namespace BlazorExample.Server.Controllers
  public class DataPortalController : Csla.Server.Hosts.HttpPortalController

This is no different from hosting the data portal in ASP.NET Core (or ASP.NET MVC) in any other setting - except that it is using that custom controller base class that works against base64 strings instead of byte arrays like normal.

Because the BlazorExample.Shared assembly is referenced by the server project, the data portal automatically has access to the same Person type that's being used by the client, so again, the normal CSLA mobile object concept just works as expected.


I estimate I spent around 20 hours fighting through the various issues listed in this blog post. As per normal, most of the solutions weren't that hard in the end, but isolating the problems, researching possible solutions, testing the various solutions, and settling on the answer - that takes time and persistence.

Also - the support from the Blazor community on gitter is really great! And the team itself via GitHub - also really great!

One comment on this - there's no debugger support in Blazor right now, hence my tweet in the middle of my work:

That did make things a lot more tedious than normal modern development. It was like a throwback to 1990 or something!

The end result though, totally worth the effort! It is so cool to see normal CSLA code running in Blazor, data bound to a UI, and interacting with an app server via the data portal!

Sunday, April 8, 2018 1:23:57 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Monday, April 2, 2018

I want to put a stake in the ground. I could be right, I could be wrong, but at least I'll have recorded this stand for future reference.

WebAssembly plus PWA technology means that the future of the "client platform" is the browser.

All existing client platforms are now officially "legacy" and will just fade away over the next couple decades. Windows, macOS, iOS, Android all are just walking dead now.

I'm not saying this will be fast, or even painless. But Microsoft is relegating Windows to second-class status, even though it runs on over a billion devices. The Mac, nice as people think it is, has never exceeded 12% market share. The smartphone market appears to be maturing - meaning it isn't growing any more, so there won't be massive income to drive new iOS or Android features.

And ultimately people have never purchased computers (including smartphones) for the OS. They purchase them because the devices run valuable apps - they do valuable things, and that means software.

Over the next few years as wasm and PWA concepts mature, we'll have browser deployed smart client apps with native (enough) performance.

Essentially, all the reasons why web sites haven't been able to compete with apps are being resolved by the wasm/PWA concepts. Web-style deployment? Browsers have that. App-style deployment? PWAs fix that. Performance? wasm fixes that. Porting existing massive codebases into the future? .NET (for example) on wasm helps address that.

I strongly suspect that Microsoft's recent org changes around Windows are just a recognition that the "client platform" of the future is whatever is necessary to run a browser that supports wasm/PWA - which is essentially all modern browsers.

What we think of as an OS today is merely a browser-delivery vehicle for the future. Something has to provide all those drivers and whatnot so browser-based apps can rely on them.

Yeah, I hear the gaming community screaming. And as one of them, I agree - I expect to continue to pump money into a "real computer" for a long time to come so I can play Battlefield and Elite Dangerous.

But for everyone else (and that's most people) the era of a "real computer" with a "real operating system" is coming to a close.

The browser with wasm/PWA is the new client platform, everything else is a vestige of a time that's come and gone.

fwiw, this was a topic of hot discussion in 1999 before the .com bubble burst. I remember speaking at various conferences and hearing big debates between fellow speakers, as well as attendees in the hallways, about whether the browser should remain a colorful-but-dumb terminal, or should become a true client platform for app dev.

That conversation was large derailed by the .com collapse (the dot bomb?). Why it has finally come back around nearly 20 years later is an interesting question unto itself.

But here we are, with the browser clearly an app dev client platform, capable of hosting rich, interactive smart client apps with web-like and app-like deployment, and (via wasm) performance at a native enough level to be viable.

Monday, April 2, 2018 8:12:20 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 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