Rockford Lhotka's Blog

Home | | CSLA .NET

 Monday, 22 August 2016

Working with .NET Core isn’t for developers focused on productivity or who want modern tools.

Why do I say this?

Because Visual Studio tooling hasn’t been released (or well-updated) to deal with .NET Core or ASP.NET Core, so you have to deal with a lot of bugs, missing features, poor templates, etc.

Generally you are probably better off relying on circa-1989 “modern tooling” like command lines and text editors (though VS Code is pretty good) at the moment.

Microsoft is working on next-gen tooling, so this isn’t a permanent issue, but it is somewhat frustrating to go back in time 25+ years when I’m used to this century’s tooling.

My biggest current frustration is that (working on CSLA .NET) I have a master solution that includes projects for all the platforms CSLA supports:

  • .NET Core (netstandard1.5)
  • Full .NET (4, 4.5, 4.6)
  • UWP
  • Xamarin (Forms, iOS, Android)
  • WinRT (Windows 8.1 and Windows Phone 8.1)

And all my actual code is in shared projects so I only have to maintain the code once, even though it builds for 11 different platform targets in total.

Normally (when you don’t have a .NET Core project in your solution) you can switch your code view between the various platforms in your solution. This is the drop-down in the top-left corner of your code window. Unfortunately when you have a .NET Core project (netstandard project) in your solution this drop-down stops working.

As a result I’m finding that I need to have 3 solutions:

  • A master solution to build everything, including netstandard
  • A non-netstandard solution to work on everything except .NET Core
  • A netstandard solution to work on the .NET Core and ASP.NET Core projects

This way, in the netstandard solution I can actually see what’s going on with the correct code and Intellisense for .NET Core:


And in my non-netstandard solution I can switch between the rest of the platforms to get the correct experience:


Three solutions where I should have (and used to have) just the one master solution.

I can’t wait until the tooling catches up to the platform so things get simpler again!

Monday, 22 August 2016 16:22:03 (Central Standard Time, UTC-06:00)  #    Disclaimer
 Monday, 25 July 2016

I have an existing .NET project (CSLA .NET) that uses resx resource files for localization. While adding support to CSLA .NET for .NET Core I had to figure out how to use resx files in a .NET Core (NetStandard 1.5) Class Library.

There is a doc for .NET Core Globalization and Localization that has good info, but it did lead me down a bad road given that I’m bringing in existing code and resx files.

There’s not currently tooling in Visual Studio 2015 for dealing with resources in .NET Core projects, or at least not like you’d expect from VS with full .NET. But there’s enough tooling that if you copy or create a Resources.resx file in a folder of your project you’ll end up with the appropriate generated designer.cs file.

Note that the Microsoft doc says that they think most of us won’t use that generated file. I think they are full of crap, because the alternative is to not use strongly typed access to your resources, and to manually craft a class to access your resources. WTF!?! So I’m ignoring their non-recommendation/supposition that I think is completely wrong, and I’m continuing to rely on the designer.cs file that has provided so much value since 2002.

The problem I encountered is that in the Microsoft doc they talk about putting your resx file(s) into a Resources folder. DO NOT DO THIS.

The tooling that generates the designer.cs file uses the folder name to create the namespace for the generated code. If you use a Resources folder the resulting name (for me) was Csla.Resources. And the class they generate is named Resources. So you have a class named ‘Csla.Resources.Resources’ – and it is a static class. As a result you basically can’t access any of the properties or methods in the class without using the full type name (no using statements allowed)!! It is a total mess.


A related problem flows from the fact that I’m using existing code, all of which assumes the resx files are in the ‘Properties’ folder, so the namespace is ‘Csla.Properties’. So really what I need is to have all my resx files in the ‘Properties’ folder within my project so the full type name of the generated code is ‘Csla.Properties.Resources’ just like it has been in .NET projects for years and years and years.

The resx code generation tool appears to only run if the Resources.resx file is really in that folder (not linked from elsewhere), so I needed a way to copy my resx file from its original location into my NetStandard project.json:

"scripts": {     "precompile": "copyResources.cmd"

And of course this means that I also have that cmd file in my project’s root folder (a peer with project.json):

del Properties\*.resx
copy ..\Csla.Shared.Resources\*.resx Properties\

Notice how I’m deleting and recopying the files on every build. This is because the master source for my resx files is in the ‘Csla.Shared.Resources’ folder, and I don’t want anyone thinking they can edit the resx file in this copy – that’d be a maintenance issue! (as an aside, I also added these copied resx files to my .gitignore file so they never get checked into source control – they are just a build artifact after all)

As soon as the Resources.resx file is copied into the folder the designer.cs file is created, which means all my code that has ‘using Csla.Properties;’ and that uses the strongly typed members from the ‘Resources’ class will all work.

However, it is also critical that the resx files be leveraged as embedded resources when the project builds. To make this happen I had to add more lines to the project.json file:

"buildOptions": {     "compile": [ "../Csla.Shared/**/*.cs" ],
    "embed": {         "include": [ "Properties/Resources.resx" ]     },
    "define": [ "NETFX_CORE", "NETCORE", "NETSTANDARD" ],     "outputName": "Csla",     "xmlDoc": true

The “embed” build option indicates that the Resources.resx file should be embedded as a resource in the compiled DLL from the project. All the other localized resx files are automatically picked up and used to create satellite assemblies just like in full .NET. The result is that my build output directory contains ‘Csla.dll’ with the default resources embedded, and satellite assemblies in per-culture folders as you’d expect.


To summarize:

  1. Do not put your Resources.resx file into a Resources folder – that way lies madness
  2. If porting existing code to .NET Core you’ll almost certainly want to put the resx files into your ‘Properties’ folder to get the same namespace as full .NET
  3. If porting existing code, use a precompile directive to copy the resource files to the target location
  4. Use the “embed” build option to embed your Resources.resx file into your assembly to make the default culture available
Monday, 25 July 2016 12:48:20 (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, 01 June 2016

csla win8_fullThis release of CSLA .NET is focused primarily on enhancing the existing Xamarin support. There is now a Csla.dll targeting PCL Profile111, which is the current profile for Xamarin.Forms projects and .NET Core.

There is also now a CSLA-Xamarin NuGet package that includes a Csla.Xaml.dll with support for Xamarin.Forms. This includes the same viewmodel base classes as the other XAML platforms, and an implementation of the PropertyInfo control tailored for use in Xamarin.Forms.

@JasonBock added even more analyzers for Visual Studio 2015 to help developers avoid common coding mistakes when building CSLA .NET business classes.

We now have support for the prerelease of Entity Framework 7.

The pt and pt-BR resources for Csla.dll have been updated. Other languages need updates as well - please contribute if you are a native speaker!

There is a new way to customize the server-side data portal by implementing an interceptor that is invoked via the new DataPortalBroker. (#564)

Full details:

The assemblies and packages are all available via NuGet.

Wednesday, 01 June 2016 09:33:18 (Central Standard Time, UTC-06:00)  #    Disclaimer
 Thursday, 10 December 2015

Starting with version 4.6.300 CSLA .NET supports ASP.NET 5 (.NET Core) and the CSLA-Core NuGet package includes a portable class library that targets .NET 4.6 and dnxcore50.

There does appear to be an issue with adding the NuGet package to an ASP.NET Class Library project. I assume this is due to the pre-release nature of the ASP.NET 5 tooling.

What happens is easy to replicate. Create an ASP.NET 5 web site project, then add a portable class library using the ASP.NET 5 template:


Then add a NuGet reference to CSLA .NET 4.6.300 (currently also in pre-release):


Then try to use features of CSLA – for example, altering the Class1 code like this:

using System;
using Csla;

namespace ClassLibrary1
    public class Class1 : BusinessBase<Class1>
         public Class1()
         { }

The project will not compile at this point even though one would expect that CSLA really has been referenced:


After some experimenting I found what appears to be a solution. The project.json file must be manually edited so CSLA is listed as a dependency not only in the “net451” framework, but also in the “dotnet5.4” framework:

   "version": "1.0.0-*",
   "description": "ClassLibrary1 Class Library",
   "authors": [ "Rockford" ],
   "tags": [ "" ],
   "projectUrl": "",
   "licenseUrl": "",
   "frameworks": {
     "net451": {
       "dependencies": {
         "CSLA-Core": "4.6.300-Beta001"
     "dotnet5.4": {
       "dependencies": { 
         "Microsoft.CSharp": "4.0.1-beta-23516",
         "System.Collections": "4.0.11-beta-23516",
         "System.Linq": "4.0.1-beta-23516",
         "System.Runtime": "4.0.21-beta-23516",
         "System.Threading": "4.0.11-beta-23516"
     “dependencies” : {
         “CSLA-Core”: “4.6.300-Beta001”

The solution/workaround is to move the “CSLA-Core”: “4.6.300-Beta001” dependency from the “net451” framework to a global dependencies section.

With this change the project will now build.

Thursday, 10 December 2015 11:31:33 (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, 06 November 2015

.NET Core is somewhat confusing to a lot of people. In short, .NET Core is an open source reimplementation of .NET that Microsoft has been, and continues to, work on completing. The Universal Windows Platform (UWP) runs on .NET Core, as does the upcoming ASP.NET 5 technology. What is a little confusing is that ASP.NET 5 also runs on full .NET 4.6 – it can run on either NET implementation.

One of the biggest things to understand about .NET Core is that Microsoft is working hard to keep it very modular. Unlike full .NET, where a lot of things are in a few assemblies, in .NET Core there are a lot of assemblies with a few things in each. And those assemblies are generally available via NuGet, not included by default as part of the “.NET Core install”. The advantage to this is that your app can be more lean, because generally we’ll bring in only the framework assemblies we need, where in full .NET a lot of unneeded stuff tends to just come along for the ride.

Getting to UWP

Some time ago I added Windows 10 UWP support to CSLA .NET, which means that I already did some work to get CSLA running on .NET Core. However, the UWP project template in Visual Studio is somewhat forgiving, in that it brings in several .NET framework components that aren’t automatically brought in if you create a bare-bones .NET Core class project. This makes sense, because there are a set of assemblies necessary to support UWP and I think we’d all expect those to be automatically available to any UWP project.

The CSLA UWP project targets Windows 10.


Or in project.json terms:

  "dependencies": {
    "Microsoft.NETCore.UniversalWindowsPlatform": "5.0.0"
  "frameworks": {
    "uap10.0": {}
  "runtimes": {
    "win10-arm": {},
    "win10-arm-aot": {},
    "win10-x86": {},
    "win10-x86-aot": {},
    "win10-x64": {},
    "win10-x64-aot": {}

Back in the Windows 8 timeframe we did a bunch of work to support the Wiindows Runtime (WinRT). WinRT is quite a lot like Silverlight, in that apps run in a sandbox and have access to a subset of .NET. So getting CSLA running for WinRT wasn’t too hard because we already supported Silverlight before Windows 8 came along. However, WinRT changed reflection in some pretty radical ways, and we had to do quite a lot of work to replicate the old-style reflection API and behaviors in the WinRT world.

UWP now runs on .NET Core, which is a reengineered subset of full .NET, and UWP apps use the WinRT API from a UI perspective. So really UWP apps are very comparable to WinRT apps. That said, Microsoft did take this opportunity to yet again tweak reflection, so I used the WINDOWS_UWP compiler symbol to provide UWP-friendly implementations of the reflection fixes we’d created for WinRT. Whew!


(to be honest, some of the code in the TypeExtensions class are basically placeholders that need more work to be complete; for example: TypeExtensions.GetConstructor is not implemented properly)

The final thing to understand about the existing UWP support is that .NET Core code can be compiled to native – in fact it will be compiled to native by the Windows Store to provide the end user with the best performance. Compiling .NET code to native is a fairly complex process and one part of that process is that the end result only contains the code that is known to be invoked – all other code is literally left out of the end result. If you don’t use reflection this is not a problem, but if you do use reflection (and CSLA does) then it is important to tell the native compilation process not to “optimize” away code you might actually be calling.

To do this you edit a file in your UWP application’s Properties folder called myapp.rd.xml. In this file you indicate the assemblies that shouldn’t be optimized. For example:

<Directives xmlns="">
  <Library Name="Csla.Uwp">
    <Assembly Name="Csla" Activate="Required All" Browse="Required All" Serialize="Required All" Dynamic="Required All" />

This says that Csla.dll shouldn’t be optimized away – which is probably fine because it isn’t very big to start with. And you absolutely must ensure that your business assemblies aren’t optimized because CSLA reflects against your business assemblies to do its work. Again, probably not a big deal because your business assembly should be containing business code and not UI assets or other large artifacts – in other words it shouldn’t be terribly large either.

This is done in your UWP app project – the one that gets built and deployed to the user – and the one that typically references your business assemblies and CSLA.

Getting to .NET Core

Given everything I just discussed regarding UWP, it seems like getting a “pure” .NET Core assembly for CSLA wouldn’t be too hard. But there were some unexpected hurdles I’ll discuss.

The first step to creating a class library project for .NET Core is to create a portable class library (PCL) project that targets .NET 4.6 and ASP.NET Core 5.0.


This creates a project with the correct functional cross-section to target .NET Core.

Some time ago I refactored the CSLA codebase so all the actual code files are in a shared project named Csla.Shared. We then have a concrete project for each target platform we support (Xamarin Android and iOS, iOS Classic, .NET 4, 4.5, 4.6, WinRT, UWP, etc.).


This new PCL project is named Csla.NetCore5.0 and it just references that pre-existing shared project to get the same code as every other version of CSLA.


As I mentioned earlier, this bare-bones class library project doesn’t bring in any more of .NET than absolutely necessary. As a result I had to add some NuGet packages required by CSLA.


Or via project.json:

  "supports": {
    "": {},
    "": {}
  "dependencies": {
    "Microsoft.NETCore": "5.0.0",
    "Microsoft.NETCore.Portable.Compatibility": "1.0.0",
    "System.Runtime.Serialization.Primitives": "4.0.10",
    "System.Runtime.Serialization.Xml": "4.0.10",
    "System.Threading.ThreadPool" : "4.0.10-beta-23409"
  "frameworks": {
    "dotnet": {
      "imports": "portable-net452"

This brings in the BCL functionality required by CSLA.

The one exception is that I didn’t bring in WCF. Instead what I’ve done at the moment is to use a NETCORE compiler directive symbol to exclude the data portal WCF channel from building as part of CSLA for .NET Core. The reason for this is that I had a conversation with one of the Microsoft engineers responsible for this, and it turns out that referencing WCF has a cascade effect where a very large percentage of .NET gets brought into scope (to support WCF).

If your app doesn’t use the WCF data portal channel you shouldn’t have to include all that extraneous code/assemblies in your app. So rather than including the WCF data portal support into core CSLA my plan is to follow the lead of .NET Core itself and break the WCF data portal channel into its own separate assembly (Create .NET Core WCF data portal channel assembly).

There’s one other issue I had to deal with, and that is that in my UWP implementation I used some WinRT APIs – and those aren’t available in “pure” .NET Core. The most notable of these is code in CSLA that captures and restores the current culture and UI culture values on the current thread. Some of this is extremely old code that used to pull the information off the current thread, and then along came WinRT that required a different approach. It turns out that in .NET 4 Microsoft introduced a new API to consolidate the old and new styles of interacting with the culture values. For example, you can now do this:

request.ClientCulture = System.Globalization.CultureInfo.CurrentCulture.Name;
request.ClientUICulture = System.Globalization.CultureInfo.CurrentUICulture.Name;

The code here works on all platforms, no need to use the current thread in .NET and some WinRT API elsewhere. Very nice!

The one catch is that setting the culture isn’t universally supported in a single model because older versions of .NET (like 4) still require the use of the Thread object. So setting the culture requires a compiler directive.

        _clientCulture = System.Globalization.CultureInfo.CurrentUICulture.Name;
        _clientUICulture = System.Globalization.CultureInfo.CurrentUICulture.Name;
        _clientCulture = System.Threading.Thread.CurrentThread.CurrentCulture.Name;
        _clientUICulture = System.Threading.Thread.CurrentThread.CurrentUICulture.Name;

And that’s it – pretty easy really – thanks to having added Silverlight support years ago, followed by WinRT support, then UWP support. All the groundwork was laid for pure .NET Core support.

(and it helped that I was doing this work in Redmond so I had direct access to Microsoft engineers that are creating .NET Core Smile )

Just at the moment this work is available in a branch of my fork:

Once I’ve done some more testing I’ll merge this into the actual CSLA master branch at:

Friday, 06 November 2015 02:11:37 (Central Standard Time, UTC-06:00)  #    Disclaimer
On this page....
Feed your aggregator (RSS 2.0)
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 2017, Marimer LLC

Send mail to the author(s) E-mail

Sign In