Our Software Design and Development Clinics focus on teaching engineers the real-world development skills that will make them more productive and effective.
Part of the class is Doug and I covering several topics, but we try to have a real focus on actually doing things. We want students to develop skill and knowledge, which takes both learning and putting that learning into practice.
For the hands-on portions of our activities, Doug and I provide students with a reference implementation. When we first started our clinics, reference application was created with the.NET Framework. But not long after, Microsoft launched this .NET Core thing.
.NET Core 1 felt like a beta release, so we skipped it. But when .NET Core 2 finally hit we were suddenly interested for many reasons, but there were a few that we found especially interesting when it comes to our clinics.
First, .NET Core runs on a variety of platforms: Windows, Mac, and Linux. While most of our students are typically Windows users, we like the idea of flexibility. Having the ability to let students use their OS of choice is nice option.
Second, porting our code to .NET Core was pretty easy. Our patterns and practices keep us isolated from platform changes having a big effect on our systems.
But what we found to be the biggest issue was with unit testing. We have always used a pattern for unit testing where we create a TransactionScope at the beginning of a unit test run and then dispose of it later. This prevents unit test data from ending up in the database.
Doing this with .NET Core turned out to be a little more difficult. With .NET Core, we had to interact with the transaction associated with the Entity Framework database context. While this wasn’t difficult, I do think the .NET Framework version is a little more eloquent.
Now moving to .NET Core wouldn’t have a huge advantage to us without changing our database from supporting SQL Server. Requiring SQL Server has probably been the biggest pain point in getting developers setup for our class (even more of a pain than requiring Windows). While making these changes we decided to move to support SQLite as a database option for our .NET Core version. We could have done this with our .NET Framework version, but while making big changes it felt like the right time to update to SQLite.
I’d like to thank Branden “Beebs” Barber and Ceren Kaplan for the work they put in to help make this happen.
If you liked what you have read here, consider signing up for our Software Design and Development Clinic.
For more fun, follow me on Twitter at @chadmichel.