Skip to content

Category: .NET Core

Initial release of Original Coder Libraries!

I’ve created the Original-Coder-Libraries repository on GitHub and uploaded some source code to get things started! They are licensed under the GNU LGPL v3.

The libraries currently contain approximately 3,500 lines of C# according to code metrics. This is a tiny fraction of what I have in my personal libraries and I’ll be adding more in the future.

The OriginalCoder.Common library includes:

  • Abstract base class for implementing IDisposable
  • Abstract base class for implementing IDiposable that also automatically cleans up registered children.
  • Exception classes for use in Original Coder libraries
  • Comprehensive set of extension methods for reading and writing XML using Linq to XML
  • Interfaces and classes for returning messages and operation results (mostly intended for use with Web APIs)
  • Extension methods for working with enumerations
  • Centralized application configuration for working with DateTimes (such as which formats to use for user display vs data storage).
  • Many useful DateTime extension methods
  • Extension methods for working with Type
  • Extension methods for calculating a cryptographic hash of a disk file
  • Standard interfaces for defining common properties on classes (Name, Description, Summary, WhenCreated, WhenDeleted, etc).
  • Extension methods for working with standard object property interfaces.

The OriginalCoder.Data library includes:

  • Standard interfaces for defining common data properties on classes (WhenCreated, WhenUpdated, WhenDeleted, IsActive).
  • Extension methods for working with standard object property interfaces.
  • Standard interfaces for defining unique key properties on classes (Id, Uid, Key)
  • Extension methods for working with standard key interfaces.


Leave a Comment

Future NuGet Libraries

Anyone who has worked with me knows I’m fairly prolific. I tend to write a lot of reusable library & framework code. I hate writing the same code twice, so most of the code I write is reusable and ends up in libraries. Over the years I’ve built up a rather massive set of my own personal C# libraries.

I’ve started work reorganizing my C# libraries so they can be put up on NuGet. Some code is quite old so I’ll likely modernize it to use newer C# features. I already have some unit tests, but I’ll likely add some more. Putting everything up is a large undertaking but I’ll put pieces up as I go along.

Due to being me, I’ll certainly write new stuff along the way. Which is actually how I got here. As part of my Adventures in .NET Core I started writing a backend framework. I’ve written this sort of thing previously for clients and it makes backend development much quicker, easier and more standardized. But I’ve never written one of my own. Writing it for myself means I don’t have to compromises or worry about deadlines, so this should be fun.

1 Comment

First impression of EF Core is very poor

Based on my experience with prior Framework versions of Entity Framework I set off to implement the new EF Core version using Database First. What I ended up finding is nothing like the experience I expected. This was the most frustrating experience I’ve had with Microsoft development tools in quite a long while.

TLDR: If you’re trying to do Database First with EF Core go get the EFCorePowerTools extension. This is what Microsoft should have provided and it will save you a lot of time and grief.

The .NET Framework versions of EF were both powerful and user friendly. Plus they gave the developer lots of options and capabilities so that they could use it the way that best made sense for the project. Tasks like generating or updating the data classes were very easy to accomplish using GUI windows. Sure the EDMX file could (rarely) get corrupted, but you are using version control, right? Just pull a known good version.

My goals for this project:

  • Use Database First because Code First doesn’t generate quality (DBA approved) schema unless you put in a lot of effort to hand code SQL DDL statements in the C# code. That’s a nightmare, so no.
  • Put the POCO classes in a .NET Standard library with minimal dependances so that they can be reused if ever needed (plus this keeps things clean)
  • Create a separate .NET Core library to contain all the Entity Framework specific code for implementing the data repository including the DbContext.
  • Reference both of those libraries from an ASP.NET Core MVC project to verify it works.

Seemed simple enough. I’ve done this numerous times with the old non-core versions of Entity Framework and it was easy. To get started I searched the Internet for instructions on how to do Database First with EF Core and I found quite a few walkthroughs. Unfortunately, none of them worked.

First problem I found is some of the walkthroughs assumed you were targeting an ASP.NET Core MVC project so they skipped steps. Found others that targeted a library but the first couple I tried failed because the list of EF Core packages has changed someone in the recent past. Finally got the library ready which included adding design and tool packages to the library because the POCO generator requires them. This library will end up getting used in production, it should not have dependencies on developer tooling and aids. Sloppy.

To generate the POCOs you have to execute a Scaffold-DbContext command in the Package Manager Console. This is not obvious and not user friendly. It also doesn’t work. I spent at least an hour and a half trying it with different arguemnts or even via the Command Prompt along with more Internet searching. It seems lots of developers have trouble with this because there are lots of pages dealing with various errors. Oh and there were multiple errors, every time I thought I fixed one thing a different error came up. It simply refused to work.

Then I got very lucky! Buried down in the comments on one of the many web pages was a link to the EFCorePowerTools Visual Studio extension. It adds GUI support for doing common tasks related to EF Core. One of those tasks is generating POCOs. Plus since its part of the GUI it doesn’t care what packages are added to the target library, so no need to add design and tooling to production libraries! Installed the extension, restarted Visual Studio and within 2 minutes I had the POCOs generated no problem.

Its worth mentioning that EFCorePowerTools is not from Microsoft! We have Erik Ejlskov Jensen to thank. Why in the world Microsoft didn’t do this themselves is beyond me. Very poor.

Before finding that extension I was keeping notes so I could write up my own web page on how to try and deal with Scaffold-DbContext. But after finding the extension I realized who cares and tossed them. Time will tell if it has any maintenance shortcomings, but for now it makes life so much better.

Leave a Comment

Adventures in .NET Core

I’ve been slowly moving towards .NET Core for awhile and have decided now is a good time to try and take the full plunge.

Initially it was just too new and incomplete to be of use. When .NET Standard reached v2 I started writing most library code in that instead of .NET Framework. By targeting .NET Standard those libraries could then be used by not only .NET Framework and .NET Core applications but also Mono, Xamarin, etc. Plus there are some other advantages to the way .NET Standard library projects work that I won’t go into here. But beyond libraries I only dabbled in .NET Core applications mainly because of Entity Framework.

Entity Framework has become an awesome, almost indispensable ORM in no small part due to the integration of LINQ. Entity Framework 6 is very capable and mature; It works. Entity Framework Core is a complete rewrite and lacks some of the capabilities present in EF6. Plus I personally find the emphasis on Code First and at best limited support for database first rather alarming. As someone with strong experience in both Software Engineering and Database Administration I’ve always suspected Code First would lead to compromises in the database. EDMX files may not be fun but they allow for a very productive workflow and don’t require any compromises.

Given the above and the fact that .NET Core has reached a good level of maturity I’ve decided it is time to set off on an adventure to explore what it can do, can’t do and how it works. In addition to .NET Core I’ll use this adventure to also try out some of the other new Microsoft technologies such as Xamarin.

To do this I’m going to come up with a small but meaningful (non-trivial) application to build. I’ll use SQL Server 2017 for database storage and make sure that the database schema includes important capabilities such as keys, indexes, GUIDs, etc. On top of that I’ll use ASP.NET MVC Core to build a RESTful API backend which will provide all the capabilities clients require. Then I’ll build multiple client applications using various technologies that access the backend API.

Now that Microsoft is finally playing nice with others there is literally a myriad of client possibilities! Just in the realm of web applications there is an almost daunting list of possibilities:

  • Old school ASP.NET Core with MVC, Razor, Bootstrap and jQuery
  • ASP.NET Core with Angular 2
  • ASP.NET Core with Knockout
  • ASP.NET Core with React
  • ASP.NET Core with React + Redux
  • Non-core ASP.NET MVC with Razor, Bootstrap and jQuery (for comparison)
  • Non-core ASP.NET Web Forms since they are still used in some older systems

There is also an impressive list of non-web client possibilities:

  • WinForms
  • Windows Presentation Foundation (WPF)
  • Universal Windows Platform
  • Android using Xamarin
  • iOS using Xamarin
  • Mac using Xamarin
  • Unity if I wanted to dabble in the world of game programming
  • Maybe even a Linux client using Mono

It would be really interesting (and fun) to build all of those and then compare them. That would be awesome, but in reality I probably don’t have that much time to spend on this. At least for now, maybe I’ll keep this going and get to all of them eventually.

Regarding web applications Angular 2, React, and Knockout apps on ASP.NET Core is a really interesting and helpful blog post by Steve Sanderson.

I’ll detail my journey through the world of .NET Core in upcoming posts.

Leave a Comment
Site and all contents Copyright © 2019 James B. Higgins. All Rights Reserved.