Rockford Lhotka

 Monday, August 22, 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, August 22, 2016 4:22:03 PM (Central Standard Time, UTC-06:00)  #    Disclaimer

MCM-logo-s.jpgOver the past few months a group of us have been working on a Mobile Kids Id Kit app for Humanitarian Toolbox and Missing Children Minnesota.

We’re nearing the point of an MVP release and think we’ll get there with one good day of work – that day is this Saturday, August 27.

The location will be in Eden Prairie, MN. Please consider joining us if you are in the area and have skills in any of these areas:

  • Xamarin mobile development
  • Xamarin Forms XAML themes or styles
  • Hockeyapp
  • Microsoft Azure web site development (ASP.NET)

This app will support iOS, Android, and Windows. It will provide parents with a valuable tool to help them in the unfortunate possibility that their child goes missing.

How often do you have a chance to apply your software development or design skills to directly and literally make the world a better place? This is your chance!

If you are already part of the development team, full details are on our Slack channel. If you are not yet part of the team, we welcome your help! Please provide me with your email address in a comment on this post or via one of the my social media channels at and I’ll get you looped into the team.

Oh yeah, and because it is summer in Minnesota, this codeathon will also be a BBQ with typical summer grillables provided!

Or, if you have the skills and time, but aren't in the Twin Cities area you can still participate in the codeathon, but you'll have to provide your own summer BBQ while you work from wherever you are :)

In other words, we have all sorts of remote collaboration technologies, the code is in GitHub - so anyone in the world should feel free to get involved!

Monday, August 22, 2016 11:13:27 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, August 12, 2016

I’ve heard a few people complaining recently because Microsoft isn’t enabling Windows 10 upgrades for all the legacy Windows 8 and 8.1 phones that exist out there in the world.

I understand that complaint and the frustration. Everyone wants the newest stuff!

The thing is that we have examples of different strategies around vendors upgrading legacy devices to their latest OS, and there appears to be no perfect answer.

For example, Apple is quite aggressive about upgrading people to the latest OS, often resulting in complaints as people agree to the upgrade and then find that their phone has become almost unusably slow.

Google/Android is less aggressive overall (I understand this is due to carrier constraints more than Google itself). But all my Android devices have been carrier unlocked, and so I’ve been able to upgrade them as each new version of Android comes out. My tablet is now entirely useless because it is so amazingly slow. Most apps just crash, and those that run are glacial. And this device is just 3-4 years old, so what gives?

Microsoft is just being (imo) upfront that if you did upgrade some devices to Windows 10 that your experience would be terrible. Just like the experiences of many people on iOS and Android. So they aren’t supporting an upgrade that would make us all cry.

I don’t know the right answer here. Is the Apple/Google approach correct? Encourage and/or let people upgrade to the point that their device is a brick? Or is Microsoft right by not allowing people to upgrade their device to where it is useless?

At the end of the day the result is the same: we all end up having to buy a newer device to run the OS we want to use.

Friday, August 12, 2016 1:25:49 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Monday, July 25, 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, July 25, 2016 12:48:20 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, July 22, 2016

I am thrilled with the “Your Groove” functionality in the Groove music app.

Years ago I begged and pleaded to get Pandora-like functionality in the (then) Zune app. Microsoft responded with SmartDJ, which later became Radio – and that has been excellent all these years – and I still use that functionality a lot.

However, this new “My Groove” feature adds a new dimension to the overall experience that I really like a lot. For example:


The Radio feature sometimes provides new music, but dynamic channels like this one provide a lot of new music. And they auto-update weekly, so they never get stale.

I’m at the point where I think I’ll cancel my SiriusXM subscription in my car, because I can just sync these playlists to my phone and play them via BlueTooth – who needs SXM Octane to find new music when Groove does a better job for a lot less money!

Friday, July 22, 2016 1:22:53 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Saturday, June 11, 2016

RDSPK20Now is the time to register for Visual Studio Live! Redmond 2016. Sure, the conference isn’t until early August, but now is the time to get early discounts and all that stuff.

This link gets you one of those discounts: RDSPK20_Reg

This is a great event, right there on the Microsoft campus – often the best of our events in terms of spontaneous opportunities to interact with your favorite Microsoft engineers – and as is the case with all the VS Live events this is the best opportunity to learn about current and future technologies around Microsoft, the web, and mobile app development.

After all my recent health issues, I’m finally back to doing a workshop. Jason Bock and I will be giving a pre-con on distributed computing, including the use of various Azure features, microservices, and of course a little bit of CSLA .NET Smile

I hope to see you there!

Saturday, June 11, 2016 3:38:10 PM (Central Standard Time, UTC-06:00)  #    Disclaimer

Tomorrow I fly to Boston for Visual Studio Live! Boston 2016. If you are attending I look forward to seeing you during the week, it should be a great event!BOSPK17

Saturday, June 11, 2016 3:30:23 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, June 7, 2016

A very common scenario for line of business apps is to edit a collthIDVUDFR8ection of items. Often this isn’t a bit collection, just a variable number of rows with a few columns to edit per row.

The MVC scaffolding supports this scenario by making it easy to create a set of pages – display the list, create a new item, edit an existing item, confirm removal of an item. And this scaffolding is quite useful, especially for scenarios where each row of data has a lot of properties to edit.

Where it isn’t so useful is in another common case, where each row of data has a small number of properties to edit (and where there are a relatively small number of rows). In this case most users would prefer to just edit all the values on a single screen, not having to navigate to the create/edit/delete pages for each row, as that is quite awkward.

What I’ve found is that there are some (ok, lots) of blog posts and code snippets showing ways to solve this problem. Much of this content dates back many years, often to MVC 2, and shows what (in my view) are some pretty hacky solutions involving client-side JavaScript that manually creates html strings that replicate (often outdated) html comparable to that generated by MVC in Razor. Other solutions use WebGrid, a seemingly little-used feature of MVC that also needs some (less hacky) JavaScript to support editing.

For my purposes, I wanted something simpler, more direct. I don’t mind some postbacks – you’d get those with the standard MVC scaffolding – I just want the user to feel like they are just editing the list of items without a lot of page navigation. Something like this:


I also don’t mind using Session in this case, because I’m building something that will, at most, be used by 0.3% of our employee base, which is currently around 600 people. If we grow enough that scaling is an issue we’ll obviously have

To that end I created a new ASP.NET MVC 5 project in Visual Studio 2015 and added the files in this gist that contain the implementation.

The ProjectListController serves up the initial page, and accepts POST operations from the browser.

The Index method displays the page with the collection data. If Session is empty the data is loaded from the database, otherwise the cached Session data is used to populate the page. Typically this means that the first time the user arrives at the page they’ll get fresh data from the database, and on postback operations the data will come from Session. Basically I’m using Session as an in-memory scratch location for the data until all edits are complete and the user clicks the button to save the data.

The POST method works differently depending on the button clicked by the user, handling add, remove, cancel, and submit operations. The operation is indicated by the value of the button, which flows into the controller through a method parameter. In every case the POST method has the full contents of the collection from the UI that flows from the browser into the method.

The add operation adds a new/empty item to the collection, updates the state in Session and allows the page to be redisplayed. This means the newly added item appears to the user, but hasn’t been saved to the database.

The remove operation removes the selected item or items from the collection, updates the state in Session and allows the page to be redisplayed. This means the removed items are no longer displayed, but haven’t been removed from the database.

The cancel/refresh operation clears Session and redisplays the page, causing the page to display fresh data from the database.

The submit operation saves the data into the database, then clears Session to ensure that when the page is redisplayed that the user gets fresh data from the database (including the newly saved changes).

The Index.cshtml view implements the page, relying on the Person.cshtml view to display each row of data from the collection. The Index view has all the buttons the user can click to trigger the postback operations to the controller as I just described.

The Person.cshtml view creates the edit controls for the properties the user should view/edit for each row.

The Person.cs file implements the model – really the viewmodel. Notice that it has a Removed property which is very UI specific, so this clearly isn’t the actual model you’d ever get/save in a database.

The controller has TODO comments indicating where code should go to invoke the data access layer to retrieve and update the database based on the in-memory collection of Person objects.

Tuesday, June 7, 2016 6:03:58 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, June 1, 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, June 1, 2016 9:33:18 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Thursday, May 26, 2016

th7JTBT6D7There is now a Csla.Xaml.PropertyInfo control for Xamarin Forms as well as WPF/UWP, so you can use the same technique to access all metastate about each property from your XAML.

This means that (now on Xamarin too) you can bind to the property value, as well as CanRead, CanWrite, IsValid, IsBusy, and various other metastate values.

Using this capability your XAML UI can provide the user with immediate and rich visual cues as to whether the user is allowed to read or write the property value, and whether the current property value is valid (and if not, why), as well as whether the property has any outstanding async business rules currently executing.

In short, all the goodness that WPF/Silverlight/UWP developers have enjoyed over the past many years is now available on Xamarin!

(or will be once CSLA .NET 4.6.400 releases in about a week – though you can try it now with the 4.6.400 prerelease available via NuGet)

Thursday, May 26, 2016 3:57:07 PM (Central Standard Time, UTC-06:00)  #    Disclaimer