Rockford Lhotka's Blog

Home | | CSLA .NET

 Monday, September 21, 2015

Universal-Windows-Platform-SmallI recently made an interesting discovery about Universal Windows Platform apps.

When you build and run them in Release mode they are compiled using the .NET Native compiler, and they stop using mscorlib.

Most of your common .NET types come out of mscorlib. For example:

System.Object, mscorlib, Version=, Culture=neutral,PublicKeyToken=7ce85d7bea7798e

When you are running UWP code in Debug mode that remains true. But in Release mode the use of mscorlib is replaced by System.Private.CoreLib. For example:

System.Object, System.Private.CoreLib, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a

In the vast majority of cases nobody cares about the assembly qualified name of a type – unless you are using reflection, in which case you may easily make this same discovery.

In my case, working on CSLA .NET, this difference posed a real challenge. One of the key features of CSLA is the concept of mobile objects, where object graphs transparently flow (move) across the tiers of your application (between AppDomains, processes, or computers over the network). For this to work, the type names of the objects must be the same in the source and destination environments, whether that be an Android client talking to a full .NET server, or a UWP client talking to that same server.

Fortunately ever since ~2007 and Silverlight’s restrictions on reflection (and the fact that it didn’t support BinaryFormatter or NetDataContractSerializer) CSLA has had its own serializer: MobileFormatter.

MobileFormatter has some serious advantages over BinaryFormatter and the NDCS, most notably it works across all platforms in a consistent manner, as well as minimizing the use of reflection and providing substantial control over the format of the byte stream transferred over the network.

In this scenario that last point is important, because I was easily able to enhance MobileFormatter to translate any assembly qualified type name that uses mscorlib or System.Private.CoreLib so the assembly name is an arbitrary text code. I chose /n. The full assembly name becomes /n during serialization, and that code becomes the full assembly name during deserialization.

The result is that types flow between UWP and all other platforms (.NET, Xamarin, etc.) transparently - as always. As a bonus this change reduces the number of bytes transferred over the wire because the full assembly name isn't in the byte stream, just this short code.

I found that benefit to be compelling enough that while I was changing MobileFormatter to solve the mscorlib issue I also added code to translate the CSLA assembly name to /c in the same manner.

In the future I may look at ways to translate user-created assembly names (your business assemblies) into short codes as well, as that would save a lot of bytes on the wire.

Monday, September 21, 2015 3:47:28 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Wednesday, September 16, 2015

Steps to repro the issue described in this github issue:

1. Pull the csla repo from

a. Switch to the NuGet-uwp branch

2. Open <root>\csla\Source\

a. Build Release | All CPU

b. Don’t worry about the Xamarin projects – they don’t matter for this issue

c. Build results will be in <root>\csla\bin

i. including the problematic rd.xml files for the UWP projects

3. Open PowerShell, cd to <root>\csla\NuGet

a. Run ‘Build All.ps1’ /prerelease:Beta3

b. Run consolidatepackages.bat

4. Open <root>\csla\Samples\ProjectTracker\ProjectTracker.sln

a. Add a NuGet package source to <root>\Packages, for example:

b. Build Debug | All CPU

i. Ignore the async method lacks await warning – this is a testing artifact

ii. Ignore the warnings about our analyzers (unless you know how to fix them – this analyzer via NuGet stuff is challenging at best!!!!)

iii. You should end up with a build error:









Payload contains two or more files with the same destination path 'Csla\Properties\Csla.Uwp.rd.xml'. Source files: C:\Users\Rockford\.nuget\packages\CSLA-Core\4.6.172-Beta3\lib\uap10.0\Csla\Properties\Csla.Uwp.rd.xmlC:\Users\Rockford\.nuget\packages\CSLA-UWP\4.6.172-Beta3\lib\uap10.0\Csla\Properties\Csla.Uwp.rd.xml



Wednesday, September 16, 2015 11:00:21 AM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Friday, September 04, 2015

In a recent blog post @praeclarum discusses frustrations with NuGet 3.

His viewpoint is from someone who uses (used?) PCLs.

What is interesting is that I agree with him about NuGet 3, but my viewpoint is as someone who chose Shared Projects over PCLs.

So I rather suspect NuGet 3 solved some unknown set of problems that somebody must have had – but it wasn’t authors of libraries using and not using PCLs. Huh.

You might ask why I don’t use PCLs – and in particular in my CSLA .NET framework, which is extremely cross platform. And that’s actually part of the answer.

CSLA .NET came into being before .NET itself was released, and has been evolving ever since. Perhaps the biggest point of evolution occurred when I chose to support Silverlight 2.0 in around 2006 (or 2007?). That was the first point where the (then years old) codebase needed to stop depending on full .NET. Also at that point in time neither PCLs nor Shared Projects existed, but Linked Files existed (the precursor to Shared Projects).

As a result, much of the CSLA Silverlight code existed as links to files in the full CSLA .NET project. So there were two different projects – one for .NET and one for Silverlight. Shortly followed by a third project when .NET Server and .NET Client split.

Of course the .NET and Silverlight platforms weren’t the same, but by using linked files each shared file was compiled for each target platform, and we were able to use compiler directives to accommodate differences in each platform.

Any real-world project tends to end up with some cruft, and CSLA is no exception. By the time we’d followed this model to add Silverlight, Windows Phone, various versions of .NET (3.5, 4, 4.5), Xamarin (iOS and Android aren’t always identical either), WinRT, and mono we’d accidentally duplicated various files and inappropriately reused some compiler directives. I wish I could say the CSLA dev team was perfect at all times, but we take shortcuts, or miscommunicate, from time to time like anyone else.

Earlier this year I undertook a major initiative to shift all the linked files into a set of common Shared Projects using the official support provided in Visual Studio 2015. The end result is really nice, but this change brought me face to face with every compromise or mistake we’d made over the past several years. Fun!

The end result is that all the actual code for CSLA resides in a small set of Shared Projects, and those projects are shared into concrete compilable projects for each target platform supported by CSLA .NET. The release folder (compiler output target) looks like this:


Then a set of NuGet 2 packages are created representing the various scenarios where people would want to use CSLA to reuse their business logic – across different user experiences and/or different platforms. The list of NuGet packages includes:

  • Core (basically Csla.dll for your platform)
  • Web (Core + Web (basic ASP.NET and Web Forms helpers))
  • MVC (Core + Web + helpers for the MVC version you are using)
  • WPF (Core + WPF helpers)
  • WinForms (Core + Windows Forms helpers)
  • WinRT/UWP (Core + WinRT and UWP helpers – which are the same right now thankfully)
  • Android (Core + Android helpers)
  • iOS (Core + iOS helpers)
  • Entity Framework (Core + helpers for the EF version you are using)
  • Validation (Core + helpers for enable backward compatibility with an older rules engine from CSLA 3.8)
  • Templates (installs VS templates and snippets on the dev workstation)

To accomplish this we have the following solution structure for the core Csla.dll outputs:


Notice that there’s one Csla.Shared project – it contains all the code – and then a set of concrete compilable projects for the various platforms and .NET versions supported. Those projects contain no code at all, just settings for the compilers.

Would a PCL simplify this? Sort of, but not really. There are too many differences between some of these target platforms for the actual implementation code to exist in a single PCL. Remember, you can’t use compiler directives or have any platform-specific implementation code in a PCL – and that constraint is just too limiting to allow CSLA to do what it does. Perhaps this is in large part because a key feature of CSLA is that it shields your business code from underlying platform differences, so we can’t dumb down the code in CSLA and allow platform differences to penetrate our abstractions or we’d lose a primary benefit of CSLA itself.

Namely, you write your business logic one time and then reuse that exact code on every platform you want to target, thus radically reducing your maintenance burden over the years you’ll be running that code.

Now there is the concept of “bait-and-switch” with a PCL, where the PCL itself contains no implementation – only public interface definitions. And then you create a concrete compilable project with the actual implementation for each platform and .NET version you want to support. In other words, you do exactly what we are doing here, with the addition of one more project that only contains all the public class/interface/type information from Csla.Shared.

And I might do this “bait-and-switch” hack someday – but to make such a thing manageable I’d want a tool I can run as part of the build process that generates all that public type information from Csla.Shared, because otherwise I’d have to maintain it all by hand and that’s just asking for trouble. (anyone knowing of such a tool feel free to let me know!!)

We follow the same basic pattern for the various UI technologies – so there are a similar set of concrete projects and one shared project for XAML, Android, iOS, Web, MVC, etc.

The result is, in my view, extremely manageable thanks to the great support for Shared Projects in Visual Studio 2015. Yes, we’ve been following this approach “the hard way” since ~2007, so I feel very confident saying that VS2015 is a major step forward in terms of tooling around this model.

I also feel comfortable saying that I have no regrets that we didn’t go down the PCL route when PCLs were introduced. They’d have required we use the “bait-and-switch” hack, which is too much magic for my taste, and I think they’d have further increased the complexity of our solution.

Back to NuGet 3 – nothing I’m talking about here requires (or currently uses) NuGet 3. Part of the build process generates a set of NuGet 2 packages that I push into NuGet:


As a result, when you add a reference to ‘CSLA MVC5’ you get the correct ‘CSLA Core’, ‘CSLA Web’, and ‘CSLA MVC’ assemblies in your project for the version of .NET your projects are targeting. Exactly what you expect. Easy for the end developer, and I think easy for us as maintainers of an OSS library.

From what I can see, NuGet 3 just changes a bunch of stuff and adds confusion to fix some problems I’m not encountering. That’s never a good sign…

Friday, September 04, 2015 6:01:31 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Thursday, August 27, 2015

csla win8_fullThis is a NuGet only release, we no longer supply an msi installer

Release details on NuGet:

Supported platforms:

  • .NET 4, 4.5, 4.6
  • Android (Xamarin)
  • iOS (Xamarin)
  • UWP (Windows 10)
  • WinRT and WinRT Phone (Windows 8.1 and Phone 8.1)

Major changes:

  • Updated to the final release of Windows 10 and the UWP SDK
  • This and all future releases will be via NuGet only (no more msi installer)
  • Removes support for Silverlight and Windows Phone 8 (Silverlight)
  • Adds support for .NET 4.6
  • Adds support for UWP (though today NuGet deploys the WinRT assemblies for UWP projects)
  • Updates iOS and Android to the latest Xamarin versions
  • Move nearly all code files into shared projects
  • WinRT, iOS, Android, UWP all now use the exact same code files as .NET in every case - which is where a lot of the risk comes from because I may or may not have gotten all the compiler directives fixed up correctly.
  • Add analyzers for Visual Studio 2015 and .NET 4.6 projects
Thursday, August 27, 2015 8:40:34 AM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Thursday, August 20, 2015

Windows-10-logoIn a recent article ‘10 reasons you shouldn’t upgrade to Windows 10’ the author ends by saying that he did upgrade even over his own objections. I can’t argue with that conclusion, as my only remaining Win7 ‘machine’ is a virtual machine I use for legacy work, and I have no Win8 devices left at all (except for my phone, and hopefully I’ll be on Win10 there soon too).

Note: to be fair, @woodyleonhard wrote another article earlier on why you should upgrade to Windows 10.

I’ve upgraded or installed Windows 10 on quite a few devices at this point, and have been using it continually for a long time as part of the Windows Insiders Program. So I thought I’d provide at least some quick thoughts on the 10 reasons “not to upgrade” based on my experience.

10. Ongoing privacy concerns

I think there’ve been a lot of good rebuttals of this issue – not least of which is that anyone using an Apple or Android (or Windows) smart phone already gave away all their privacy anyway Smile

Perhaps more useful is this good article about what Windows 10’s privacy settings actually do.

9. OneDrive regression

There’s some truth to this – I liked the way Win8.1 did OneDrive. Apparently the Win8.1 approach confused a lot of people though – including several of my co-workers. OneDrive in Win10 now it works more like DropBox. I’m personally unconvinced that this is a big deal one way or the other.

For me the big thing was access to my massive library of photos in OneDrive, and when I discovered that the Win10 file open dialog (from Universal apps) can tap into the Photos app (and other file sharing apps like DropBox) to get at cloud-based files my life was greatly improved.


8. Missing Media Center and DVD player

VLC (from the store, and for desktop), k-lite, and CCCP solve this problem just fine, in terms of playing DVDs anyway. I suspect that’s the biggest issue for most people.

If you are an actual Media Center user then I agree, don’t upgrade until you’ve found a replacement solution. You might consider one of the numerous other options that run on Linux and/or Windows.

7. Not much in the way of Universal apps

This isn’t new – there were relatively few good apps in the store for Win8.1 – and it continues to be frustrating into Win10. I really hope that the new UWP and UWP bridge technologies help bring a lot more apps to Win10. That, and the reality that there are nearly 100 million Win10 installs already (in the first few weeks the OS has been out) so you’d think that app authors would start to care about reaching this audience.

On the other hand, if you are a Win7 user then why would this be a roadblock to moving to Win10? You have zero apps in Win7, so what little is in the store is infinitely more than what you have today.

And if you are a Win8.1 user there aren’t less apps than what you have, there just aren’t really any more apps either.

6. Key apps, including Mail and Edge, aren’t ready yet

I’ll argue here about Edge, because I like it a lot. I know it doesn’t yet have some features of more mature browsers, but then again it is lighter and faster than they are and I like that trade-off.

On the other hand, the points about the Mail (and Calendar and People) apps are totally on point. I’m extremely disappointed that these apps weren’t (imo) completed before Win10 shipped, and every day when Mail crashes or messes up in other ways I wish for a higher quality app. They are getting better fairly rapidly, but today they are frustrating.

If you are coming from Win7 you don’t have these apps and so perhaps won’t care. If you have Outlook you won’t care, because you’ll probably keep using Outlook.

But I really, really liked the Win8.1 mail/calendar/people apps and can’t wait for the Win10 versions to catch up to their 8.1 predecessors.

5. Win10’s Tablet Mode may not appeal to you

If you are upgrading from Win7 you almost certainly don’t have a tablet, so moving to Win10 with tablet mode is immaterial because you’ll never use tablet mode. Not a roadblock.

If you are one of the few people that does have a Win7 tablet then how do you live with it??? And if you do, then Win10’s tablet mode with be nothing but an improvement. Again, not a roadblock.

If you are on Win8.1 with a tablet then Win10’s tablet mode is basically the same thing you have today. Nothing to lose in this case, but if you sometimes use a keyboard/mouse with your tablet then there is a lot to be gained by upgrading to Win10.

4. The installer may not be ready for you yet

Having upgraded quite a number of machines (including my father-in-law’s old laptop) without any issues I must say that Win10 is the first time in Windows history that I would recommend doing an upgrade rather than a fresh install. I’m amazed at the upgrade process and how well it works.

That said, if the installer isn’t ready for you it is probably because some hardware vendor for some component in your computer hasn’t released a Windows 10 driver yet. That’s increasingly rare, but if you are in that situation then you really don’t want to upgrade yet – not until the drivers are available.

3. Forced updates

I don’t really know what to say about this one. Not forcing updates is bad because people fall behind and end up vulnerable to viruses and malware, but forcing updates is causing some issues. It seems to me that the solution is to roll forward on the current course and for Microsoft to figure out how to make forced updates work reliably.

As (I hope) more apps end up in the Windows Store they’ll tend to only run on the current version of Windows, so not applying updates almost certainly means your apps will stop working. I personally use a lot of apps from the store, and I sure don’t want them to stop running because I missed an update!

2. Ain’t broke, don’t fix

This is somewhat short-sighted. I get the idea here, just like most people stick with old versions of OSX, iOS, or Android (note my sarcasm: most people don’t stick with old versions of those operating systems).

Enterprises being slow I understand, but most users of personal devices should just keep current in my view. Take advantage of the new shiny stuff, and stay with the most supported version of any OS to help avoid viruses and malware.

1. Questions, questions, questions

This isn’t a real point at all – just FUD because the author is (presumably) being paid by the word. Then on the next page he goes on to say that he upgraded anyway, because really, who wants to be stuck in the past when you have a free avenue into the future?

My conclusion

In summary, I haven’t hesitated to upgrade numerous computers to Windows 10, including computers for non-experts such as relatives and some friends. The transition from Windows 7 to Windows 10 is pretty easy for most people, it is much the same but a little prettier. The transition from Windows 8 to Windows 10 is nearly always an improvement – in desktop and tablet modes.

So yes, I am in favor of most people upgrading.

Thursday, August 20, 2015 11:49:12 AM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [2]  | 
 Thursday, August 06, 2015

After last night’s big cumulative update of Windows 10 one of my devices (my primary desktop) had some issues. Specifically, there were 4 apps the store wanted to update, but it seemed unable to download any of them (even after numerous reboots and running wsreset). And the Mail/Calendar apps were frozen; they’d launch but freeze.

The solution was in this article: (followed by a reboot and then re-running wsreset).

My region/format setting in Control Panel (the old Win32 one) was set to the default:


And the fix was to change it to my explicit region:


To easily get to this dialog, press windows-x and select ‘Control Panel’. Then in the search box (upper-right corner) type ‘Region’ and click the one search result to open the dialog shown here. Then reboot.

Why this works I don’t know – clearly something gets confused deep inside Windows – but as long as the problem is solved I’m happy Smile

Thursday, August 06, 2015 9:43:19 AM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Thursday, July 30, 2015

It seems to be a common problem with the Windows 10 store to have issues downloading or updating apps. Any message you see is probably something like “Windows Store - Error Code: 0x80070005” or “Error Code: 0x803f7000”.

The problem seems to be that some metadata related to the store gets corrupted, because more often than not the solution is to run wsreset, a utility that resets the store app.

The wsreset utility is installed with Windows 10, so all you need to do is press the Windows key and type ‘wsreset’.


Click or tap the wsreset app to run it.

Some people find that it works best to immediately reboot the computer, then open the store and your downloads should work. I find that the reboot is not typically required, so your mileage may vary.

Thursday, July 30, 2015 11:51:06 AM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Sunday, July 26, 2015

I am very excited about the upcoming CSLA .NET 4.6 release – just a few days away now.

Thanks to Jason Bock we'll now have analyzers in Visual Studio 2015 to help you identify and fix some of the most common coding errors when building business classes.

And of course we've added support for .NET 4.6, Universal Windows Platform, and the latest Xamarin iOS/Android versions.

Here’s a list of the existing/planned changes.

Sunday, July 26, 2015 12:42:21 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
On this page....
Feed your aggregator (RSS 2.0)
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 2015, Marimer LLC

Send mail to the author(s) E-mail

Sign In