Scott Hanselman

Updating my ASP.NET podcast site to System.Text.Json from Newtonsoft.Json

January 10, '20 Comments [11] Posted in DotNetCore
Sponsored By

JSON LogoNow that .NET Core 3.1 is LTS (Long Term Support) and will be supported for 3 years, it's the right time for me to update all my .NET Core 2.x sites to 3.1. It hasn't take long at all and the piece of mind is worth it. It's nice to get all these sites (in the Hanselman ecosystem LOL) onto the .NET Core 3.1 mainline.

While most of my sites working and running just fine - the upgrade was easy - there was an opportunity with the podcast site to move off the venerable Newtonsoft.Json library and move (upgrade?) to System.Text.Json. It's blessed by (and worked on by) James Newton-King so I don't feel bad. It's only a good thing. Json.NET has a lot of history and existed before .NET Standard, Span<T>, and existed in a world where .NET thought more about XML than JSON.

Now that JSON is essential, it was time that JSON be built into .NET itself and System.Text.Json also allows ASP.NET Core to existed without any compatibility issues given its historical dependency on Json.NET. (Although for back-compat reasons you can add Json.NET back with one like using AddJsonOptions if you like).

Everyone's usage of JSON is different so your mileage will depend on how much of Json.NET you used, how much custom code you wrote, and how deep your solution goes. My podcast site uses it to access a number of JSON files I have stored in Azure Storage, as well as to access 3rd party RESTful APIs that return JSON. My podcast site's "in memory database" is effectively a de-serialized JSON file.

I start by bringing in two namespaces, and removing Json.NET's reference and seeing if it compiles! Just rip that Band-Aid off fast and see if it hurts.

using System.Text.Json;
using System.Text.Json.Serialization;

I use Json Serialization in Newtonsoft.Json and have talked before about how much I like C# Type Aliases. Since I used J as an alias for all my Attributes, that made this code easy to convert, and easy to read. Fortunately things like JsonIgnore didn't have their names changed so the namespace was all that was needed there.

NOTE: The commented out part in these snippets is the Newtonsoft bit so you can see Before and After

//using J = Newtonsoft.Json.JsonPropertyAttribute;
using J = System.Text.Json.Serialization.JsonPropertyNameAttribute;

/* SNIP */

public partial class Sponsor
{
[J("id")]
public int Id { get; set; }

[J("name")]
public string Name { get; set; }

[J("url")]
public Uri Url { get; set; }

[J("image")]
public Uri Image { get; set; }
}

I was using Newtonsoft's JsonConvert, so I changed that DeserializeObject call like this:

//public static v2ShowsAPIResult FromJson(string json) => JsonConvert.DeserializeObject<v2ShowsAPIResult>(json, Converter.Settings);
public static v2ShowsAPIResult FromJson(string json) => JsonSerializer.Deserialize<v2ShowsAPIResult>(json);

In other classes some of the changes weren't stylistically the way I'd like them (as an SDK designer) but these things are all arguable either way.

For example, ReadAsAsync<T> is a super useful extension method that has hung off of HttpContent for many years, and it's gone in .NET 3.x. It was an extension that came along for the write inside Microsoft.AspNet.WebApi.Client, but it would bring Newtonsoft.Json back along for the ride.

In short, this Before becomes this After which isn't super pretty.

return await JsonSerializer.DeserializeAsync<List<Sponsor>>(await res.Content.ReadAsStreamAsync());
//return await res.Content.ReadAsAsync<List<Sponsor>>();

But one way to fix this (if this kind of use of ReadAsAsync is spread all over your app) is to make your own extension class:

public static class HttpContentExtensions
{
public static async Task<T> ReadAsAsync<T>(this HttpContent content) =>
await JsonSerializer.DeserializeAsync<T>(await content.ReadAsStreamAsync());
}

My calls to JsonConvert.Serialize turned into JsonSerializer.Serialize:

//public static string ToJson(this List<Sponsor> self) => JsonConvert.SerializeObject(self);
public static string ToJson(this List<Sponsor> self) => JsonSerializer.Serialize(self);

And the reverse of course with JsonSerializer.Deserialize:

//public static Dictionary<string, Shows2Sponsor> FromJson(string json) => JsonConvert.DeserializeObject<Dictionary<string, Shows2Sponsor>>(json);
public static Dictionary<string, Shows2Sponsor> FromJson(string json) => JsonSerializer.Deserialize<Dictionary<string, Shows2Sponsor>>(json);

All in all, far easier than I thought. How have YOU found System.Text.Json to work in your apps?


Sponsor: When DevOps teams focus on fixing new flaws first, they can add to mounting security debt. Veracode’s 2019 SOSS X report spotlights how developers can reduce fix rate times by 72% with frequent scans.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb

Yori - The quiet little CMD replacement that you need to install NOW

January 8, '20 Comments [14] Posted in Tools
Sponsored By

I did a post on the difference between a console, a terminal, and a shell a while back. We talk a lot about alternative "Terminals" like the Windows Terminal (that you should download immediately) but not shells. You do see a lot of choices in the Linux space with the top give being Bash, Zsh, Fish, Tcsh, and Ksh but not a lot about alternative shells for Windows. Did you love 4DOS? Well, READ ON. (Yes I know TCC is a thing, but Yori is a different thing)

So let's talk about a quiet little CMD replacement shell that is quietly taking over my life. You should check it out and spend some time with it. It's called Yori and it's open source and it's entirely written by one Malcolm Smith. It deserves your attention and respect because Yori has quickly become my goto "DOS but not DOS" prompt.

Yori is DOS, kinda

Of course, cmd.exe isn't DOS but it's evocative of DOS and it's "Close enough to be DOS." It'll run .cmd files and batch files. If dir, and del *.*, and rd /s feels more intuitive to you than bash shell commands, Yori will fit into your life nicely.

I use PowerShell a lot as a shell and I use Bash via WSL and Ubuntu but since I started on CMD (or command.com, even) Yori feels very comfortable because it's literally "CMD reimagined."Yori offers a number of cmd++ enhancements like:

  • Autocomplete suggestions as you type
  • Ctrl+to select Values
  • WAY better Tab completiion
  • Awesome file matching
  • Beyond MAX_PATH support for "DOS"
  • Rich Text Copy!
  • Backquote support
  • Background Jobs like Unix but for DOS. SO you can use & like a real person!
  • Alias! My goodness!
  • which (like where, but it's which!) command
  • hexdump, lines, touch, and more great added tools
  • lots of "y" utils like ydate and ymem and ymore.
  • New Environment variables make your batch files shine
  • ANSI colors/UTF-8 support!

Download Yori, make a link, pin it, or add it to your Windows Terminal of choice (see below), and then explore the extensive Guide To Yori.

Did I mention & jobs support! How often have you done a copy or xcopy and wanted to &! it and then check it later with job? Now you can!

C:\Users\Scott\Desktop>dir &!
Job 2: c:\Program Files\Yori\ydir.exe
C:\Users\Scott\Desktop>job
Job 1 (completed): c:\Program Files\Yori\ydir.exe
Job 2 (executing): c:\Program Files\Yori\ydir.exe
Job 2 completed, result 0: c:\Program Files\Yori\ydir.exe

Yori also support updating itself with "ypm -u" which is clever. Other lovely Yori-isms that will make you smile?

  • cd ~ - it works
  • cd ~desktop - does what you think it'd do
  • Win32 versions of UNIX favorites including cut, date, expr, fg, iconv, nice, sleep, split, tail, tee, wait and which
  • dir | clip - supports HTML as well!
  • durable command history

And don't minimize the amount of work that's happened here. It's a LOT. And it's a great balance between compatibility and breaking compatibility to bring the best of the old and the best of the new into a bright future.

Other must-have Malcolm Smith Tools

Now that I've "sold" you Yori (it's free!) be sure to pick up sdir (so good, a gorgeous dir replacement) and other lovely tools that Malcolm has written and put them ALL in your c:\utils folder (you have one, right? Make one! Put it in DropBox/OneDrive! Then add it to your PATH on every machine you have!) and enjoy!

Yori is lovely, paired with SDIR

Adding Yori to the Windows Terminal

Yori includes it's own improved Yori-specific terminal (to go with the Yori shell) but it also works with your favorite terminal.

If you are using the Windows Terminal, head over to your settings file (from the main Windows Terminal menu) and add something like this for a Yori menu. You don't need all of this, just the basics like commandline. I added my own colorScheme and tabTitle. You can salt your own to taste.

{
"acrylicOpacity": 0.85000002384185791,
"closeOnExit": true,
"colorScheme": "Lovelace",
"commandline": "c://Program Files//Yori//yori.exe",
"cursorColor": "#00FF00",
"cursorHeight": 25,
"cursorShape": "vintage",
"fontFace": "Cascadia Code",
"fontSize": 20,
"guid": "{7d04ce37-c00f-43ac-ba47-992cb1393215}",
"historySize": 9001,
"icon": "ms-appdata:///roaming/cmd-32.png",
"name": "DOS but not DOS",
"padding": "0, 0, 0, 0",
"snapOnInput": true,
"startingDirectory": "C:/Users/Scott/Desktop",
"tabTitle": "DOS, Kinda",
"useAcrylic": true
},

Great stuff!

I want YOU, Dear Reader, to head over to https://github.com/malxau/yori right now and give Yori and Malcolm a STAR. He's got 110 as of the time of this posting. Let's make that thousands. There's so many amazing folks out there quietly writing utilities for themselves, tirelessly, and a star is a small thing you can do to let them know "I see you and I appreciate you."


Sponsor: Curious about the state of software security as we head into 2020? Check out Veracode’s 2019 SOSS X report to learn common vulnerability types, how to improve fix rates, and crucial industry data.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb

The wires are crossed, literally! - Learning low level computing with Ben Eater's 6502 kit

December 20, '19 Comments [0] Posted in Hardware | Musings
Sponsored By

I've blogged about the importance of the LED Moment. You know, that moment when you get it to blink.

Ben Eater is a bit of an internet legend. His site at https://eater.net has a shop and YouTube videos where he's creating educational videos showing low level (and some what historical) computing.

He's known for "building an 8-bit CPU from scratch."

This tutorial walks through building a fully programmable 8-bit computer from simple logic gates on breadboards.

imageSimple logic gates? Yep, like && and || and 7400 series chips and what not. I learned on these 25 years ago in college and I sucked at it. I think I ended up making A CLOCK. Ben makes A COMPUTER.

This Christmas my gift to myself was to learn to build a 6502 computer (that's the processor that powered the Apple ][, the NES, the C64, the BBC Micro and more - it's literally the processor of my entire childhood). Ben has made the videos available free on YouTube and the parts list can be sourced however you'd like, but I chose to get mine directly from Ben as he's done all the work of putting the chips and wires in a box. I got the 6502 Computer Kit, the Clock Module Kit, and an EEPROM Programmer. I also ordered a Quimat 2.4" TFT Digital Oscilloscope Kit which is AMAZING for the value. Later I ordered a Pokit Oscilloscope that will use my phone for the screen.

I'm about halfway through the videos. There are 4 videos of about 1 hour each, but I've been following along and pausing. Ben will wire something up and speed up the video, so each 1 hour video has taken me about 4-5 hours of actual time, as I'm cutting and stripping wires manually and trying to get my board to look and behave like Ben's in the video. More importantly, I made the promise to myself that I'd not continue if I didn't understand (mostly) what was happening AND I wouldn't continue if my board didn't actually work.

At the middle-end of Video 2, we're hooking up a newly flashed EEPROM that has our computer program on it. This isn't even at Assembly Language yet - we're writing the actual Hex Codes of the processor instructions into a 32768 byte long binary file and then flashing the result to an EEPROM and reseating it each time.

Madness! Flashing an EEPROM

I'd respectfully ask that you follow me on Instragram as I'm documenting my experience in photos.

A few days ago I was manually stepping (one clock pulse at a time) through some code and I kept getting "B2" - and by "getting" that value, I mean that quite literally there are 8 blue wires coming off the data line (8 pins) on an EEPROM and they are going to turn 8 LEDs on or off. I wanted to get the number "AA."

What. I'm getting B2, I want AA. I have no idea. Do I pull it apart and redo the whole board? How many hours ago did I make a mistake? 3? 7? I was sad and dejected.

And I stared.

But then I thought. Why is AA is a lovely hex number? Because it's as it's alternating 1s and 0s, of 10101010.

I was getting B2 which is 10110010.

10110010

10110010

I had swapped two of the wires going from the EEPROM to the Processor. I was getting exactly what I asked for. I swapped to wires/pins so the bins were swapped.

I wasn't groking it until I stopped a thought and looked from multiple angles. What am I doing? What's my goal? What is physically happening here? What abstractions have I added? (even voltage -> binary -> hex is three abstractions!)

It seems a small and stupid thing. Perhaps you, Dear Reader, immediately knew what I had done wrong and were shouting it at this blog post 3 paragraphs ago. Perhaps you've never spent 13 hours debugging a Carriage Return.

But I didn't understand. And then I did. And I swapped two wires and it worked, dammit. Here is a video of it working, in fact.

It felt very good. My jaw dropped.

I feel like NOW, today, I'm ready to go to college and fix my B in Electronics Class.

Youth is wasted on the young, my friends. What have YOU been learning lately?


Sponsor: Like C#? We do too! That’s why we've developed a fast, smart, cross-platform .NET IDE which gives you even more coding power. Clever code analysis, rich code completion, instant search and navigation, an advanced debugger... With JetBrains Rider, everything you need is at your fingertips. Code C# at the speed of thought on Linux, Mac, or Windows. Try JetBrains Rider today!

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb

Setting up Azure DevOps CI/CD for a .NET Core 3.1 Web App hosted in Azure App Service for Linux

December 18, '19 Comments [12] Posted in Azure | DotNetCore
Sponsored By

Following up on my post last week on moving from App Service on Windows to App Service on Linux, I wanted to make sure I had a clean CI/CD (Continuous Integration/Continuous Deployment) pipeline for all my sites. I'm using Azure DevOps because it's basically free. You get 1800 build minutes a month FREE and I'm not even close to using it with three occasionally-updated sites building on it.

Last Post: I updated one of my websites from ASP.NET Core 2.2 to the latest LTS (Long Term Support) version of ASP.NET Core 3.1 this week. I want to do the same with my podcast site AND move it to Linux at the same time. Azure App Service for Linux has some very good pricing and allowed me to move over to a Premium v2 plan from Standard which gives me double the memory at 35% off.

Setting up on Azure DevOps is easy and just like signing up for Azure you'll use your Microsoft ID. Mine is my gmail/gsuite, in fact. You can also login with GitHub creds. It's also nice if your project makes NuGet packages as there's an integrated NuGet Server that others can consume libraries from downstream before (if) you publish them publicly.

Azure DevOps

I set up one of my sites with Azure DevOps a while back in about an hour using their visual drag and drop Pipeline system which looked like this:

Old Pipeline Style

There's some controversy as some folks REALLY like the "classic" pipeline while others like the YAML (Yet Another Markup Language, IMHO) style. YAML doesn't have all the features of the original pipeline yet, but it's close. It's primary advantage is that the pipeline definition exists as a single .YAML file and can be checked-in with your source code. That way someone (you, whomever) could import your GitHub or DevOps Git repository and it includes everything it needs to build and optionally deploy the app.

The Azure DevOps team is one of the most organized and transparent teams with a published roadmap that's super detailed and they announce their sprint numbers in the app itself as it's updated which is pretty cool.

When YAML includes a nice visual interface on top of it, it'll be time for everyone to jump but regardless I wanted to make my sites more self-contained. I may try using GitHub Actions at some point and comparing them as well.

Migrating from Classic Pipelines to YAML Pipelines

If you have one, you can go to an existing pipeline in DevOps and click View YAML and get some YAML that will get you most of the way there but often includes some missing context or variables. The resulting YAML in my opinion isn't going to be as clean as what you can do from scratch, but it's worth looking at.

In decided to disable/pause my original pipeline and make a new one in parallel. Then I opened them side by side and recreated it. This let me learn more and the result ended up cleaner than I'd expected.

Two pipelines side by side

The YAML editor has a half-assed (sorry) visual designer on the right that basically has Tasks that will write a little chunk of YAML for you, but:

  • Once it's placed you're on your own
    • You can't edit it or modify it visually. It's text now.
  • If your cursor has the insert point in the wrong place it'll mess up your YAML
    • It's not smart

But it does provide a catalog of options and it does jumpstart things. Here's my YAML to build and publish a zip file (artifact) of my podcast site. Note that my podcast site is three projects, the site, a utility library, and some tests. I found these docs useful for building ASP.NET Core apps.

  • You'll see it triggers builds on the main branch. "Main" is the name of my primary GitHub branch. Yours likely differs.
  • It uses Ubuntu to do the build and it builds in Release mode. II
  • I install the .NET 3.1.x SDK for building my app, and I build it, then run the tests based on a globbing *tests pattern.
  • I do a self-contained publish using -r linux-x64 because I know my target App Service is Linux (it's cheaper) and it goes to the ArtifactStagingDirectory and I name it "hanselminutes." At this point it's a zip file in a folder in the sky.

Here it is:

trigger:
- main

pool:
vmImage: 'ubuntu-latest'

variables:
buildConfiguration: 'Release'

steps:

- task: UseDotNet@2
displayName: ".NET Core 3.1.x"
inputs:
version: '3.1.x'
packageType: sdk
- script: dotnet build --configuration $(buildConfiguration)
displayName: 'dotnet build $(buildConfiguration)'

- task: DotNetCoreCLI@2
displayName: "Test"
inputs:
command: test
projects: '**/*tests/*.csproj'
arguments: '--configuration $(buildConfiguration)'

- task: DotNetCoreCLI@2
displayName: "Publish"
inputs:
command: 'publish'
publishWebProjects: true
arguments: '-r linux-x64 --configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)'
zipAfterPublish: true

- task: PublishBuildArtifacts@1
displayName: "Upload Artifacts"
inputs:
pathtoPublish: '$(Build.ArtifactStagingDirectory)'
artifactName: 'hanselminutes'

Next I move to the release pipeline. Now, you can also do the actual Azure Publish to a Web App/App Service from a YAML Build Pipeline. I suppose that's fine if your site/project is simple. I wanted to have dev/test/staging so I have a separate Release Pipeline.

The Release Pipelines system in Azure DevOps can pull an "Artifact" from anywhere - GitHub, DevOps itself natch, Jenkins, Docker Hub, whatever. I set mine up with a Continuous Deployment Trigger that makes a new release every time a build is available. I could also do Releases manually, with specific tags, scheduled, or gated if I'd liked.

Continuous Deployment Trigger

Mine is super easy since it's just a website. It's got a single task in the Release Pipeline that does an Azure App Service Deploy. I can also deploy to a slot like Staging, then check it out, and then swap to Production later.

There's nice integration between Azure DevOps and the Azure Portal so I can see within Azure in the Deployment Center of my App Service that my deployments are working:

Azure Portal and DevOps integration

I've found this all to be a good use of my staycation and even though I'm just a one-person company I've been able to get a very nice automated build system set up at very low cost (GitHub free account for a private repo, 1800 free Azure DevOps minutes, and an App Service for Linux plan) A basic starts at $13 with 1.75Gb of RAM but I'm planning on moving all my sites over to a single big P1v2 with 3.5G of RAM and an SSD for around $80 a month. That should get all of my ~20 sites under one roof for a price/perf I can handle.


Sponsor: Like C#? We do too! That’s why we've developed a fast, smart, cross-platform .NET IDE which gives you even more coding power. Clever code analysis, rich code completion, instant search and navigation, an advanced debugger... With JetBrains Rider, everything you need is at your fingertips. Code C# at the speed of thought on Linux, Mac, or Windows. Try JetBrains Rider today!

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb

Moving an ASP.NET Core from Azure App Service on Windows to Linux by testing in WSL and Docker first

December 13, '19 Comments [5] Posted in DotNetCore | Linux
Sponsored By

I updated one of my websites from ASP.NET Core 2.2 to the latest LTS (Long Term Support) version of ASP.NET Core 3.1 this week. Now I want to do the same with my podcast site AND move it to Linux at the same time. Azure App Service for Linux has some very good pricing and allowed me to move over to a Premium v2 plan from Standard which gives me double the memory at 35% off.

My podcast has historically run on ASP.NET Core on Azure App Service for Windows. How do I know if it'll run on Linux? Well, I'll try it see!

I use WSL (Windows Subsystem for Linux) and so should you. It's very likely that you have WSL ready to go on you machine and you just haven't turned it on. Combine WSL (or the new WSL2) with the Windows Terminal and you're in a lovely spot on Windows with the ability to develop anything for anywhere.

First, let's see if I can run my existing ASP.NET Core podcast site (now updated to .NET Core 3.1) on Linux. I'll start up Ubuntu 18.04 on Windows and run dotnet --version to see if I have anything installed already. You may have nothing. I have 3.0 it seems:

$ dotnet --version
3.0.100

Ok, I'll want to install .NET Core 3.1 on WSL's Ubuntu instance. Remember, just because I have .NET 3.1 installed in Windows doesn't mean it's installed in my Linux/WSL instance(s). I need to maintain those on my own. Another way to think about it is that I've got the win-x64 install of .NET 3.1 and now I need the linux-x64 one.

  • NOTE: It is true that I could "dotnet publish -r linux-x64" and then scp the resulting complete published files over to Linux/WSL. It depends on how I want to divide responsibility. Do I want to build on Windows and run on Linux/Linux? Or do I want to build and run from Linux. Both are valid, it just depends on your choices, patience, and familiarity.
  • GOTCHA: Also if you're accessing Windows files at /mnt/c under WSL that were git cloned from Windows, be aware that there are subtleties if Git for Windows and Git for Ubuntu are accessing the index/files at the same time. It's easier and safer and faster to just git clone another copy within the WSL/Linux filesystem.

I'll head over to https://dotnet.microsoft.com/download and get .NET Core 3.1 for Ubuntu. If you use apt, and I assume you do, there's some preliminary setup and then it's a simple

sudo apt-get install dotnet-sdk-3.1

No sweat. Let's "dotnet build" and hope for the best!

Building my site under WSL

It might be surprising but if you aren't doing anything tricky or Windows-specific, your .NET Core app should just build the same on Windows as it does on Linux. If you ARE doing something interesting or OS-specific you can #ifdef your way to glory if you insist.

Bonus points if you have Unit Tests - and I do - so next I'll run my unit tests and see how it goes.

OPTION: I write things like build.ps1 and test.ps1 that use PowerShell as PowerShell is on Windows already. Then I install PowerShell (just for the scripting, not the shelling) on Linux so I can use my .ps1 scripts everywhere. The same test.ps1 and build.ps1 and dockertest.ps1, etc just works on all platforms. Make sure you have a shebang #!/usr/bin/pwsh at the top of your ps1 files so you can just run them (chmod +x) on Linux.

I run test.ps1 which runs this command

dotnet test /p:CollectCoverage=true /p:CoverletOutputFormat=lcov /p:CoverletOutput=./lcov .\hanselminutes.core.tests

with coverlet for code coverage and...it works! Again, this might be surprising but if you don't have any hard coded paths, make any assumptions about a C:\ drive existing, and avoid the registry and other Windows-specific things, things work.

Test Run Successful.
Total tests: 23
Passed: 23
Total time: 9.6340 Seconds

Calculating coverage result...
Generating report './lcov.info'

+--------------------------+--------+--------+--------+
| Module | Line | Branch | Method |
+--------------------------+--------+--------+--------+
| hanselminutes.core.Views | 60.71% | 59.03% | 41.17% |
+--------------------------+--------+--------+--------+
| hanselminutes.core | 82.51% | 81.61% | 85.39% |
+--------------------------+--------+--------+--------+

I can build, I can test, but can I run it? What about running and testing in containers?

I'm running WSL2 on my system and I've doing all this in Ubuntu 18.04 AND I'm running the Docker WSL Tech Preview. Why not see if I can run my tests under Docker as well? From Docker for Windows I'll enabled the Experimental WSL2 support and then from the Resources menu, WSL Integration I'll enable Docker within my Ubuntu 18.04 instance (your instances and their names will be your own).

Docker under WSL2

I can confirm it's working with "docker info" under WSL and talking to a working instance. I should be able to run "docker info" in BOTH Windows AND WSL.

$ docker info
Client:
Debug Mode: false

Server:
Containers: 18
Running: 18
Paused: 0
Stopped: 0
Images: 31
Server Version: 19.03.5
Storage Driver: overlay2
Backing Filesystem: extfs
...snip...

Cool. I remembered I also I needed to update my Dockerfile as well from the 2.2 SDK on the Docker hub to the 3.1 SDK from Microsoft Container Registry, so this one line change:

#FROM microsoft/dotnet:2.2-sdk AS build
FROM mcr.microsoft.com/dotnet/core/sdk:3.1 as build

as well as the final runtime version for the app later in the Dockerfile. Basically make sure your Dockerfile uses the right versions.

#FROM microsoft/dotnet:2.1-aspnetcore-runtime AS runtime
FROM mcr.microsoft.com/dotnet/core/aspnet:3.1 AS runtime

I also volume mount the tests results so there's this offensive If statement in the test.ps1. YES, I know I should just do all the paths with / and make them relative.

#!/usr/bin/pwsh
docker build --pull --target testrunner -t podcast:test .
if ($IsWindows)
{
 docker run --rm -v d:\github\hanselminutes-core\TestResults:/app/hanselminutes.core.tests/TestResults podcast:test
}
else
{
 docker run --rm -v ~/hanselminutes-core/TestResults:/app/hanselminutes.core.tests/TestResults podcast:test
}

Regardless, it works and it works wonderfully. Now I've got tests running in Windows and Linux and in Docker (in a Linux container) managed by WSL2. Everything works everywhere. Now that it runs well on WSL, I know it'll work great in Azure on Linux.

Moving from Azure App Service on Windows to Linux

This was pretty simple as well.

I'll blog in detail how I build andd eploy the sites in Azure DevOps and how I've moved from .NET 2.2 with Classic "Wizard Built" DevOps Pipelines to a .NET Core 3.1 and a source control checked-in YAML pipeline next week.

The short version is, make a Linux App Service Plan (remember that an "App Service Plan " is a VM that you don't worry about. See in the pick below that the Linux Plan has a penguin icon. Also remember that you can have as many apps inside your plan as you'd like (and will fit in memory and resources). When you select a "Stack" for your app within Azure App Service for Linux you're effectively selecting a Docker Image that Azure manages for you.

I started by deploying to staging.mydomain.com and trying it out. You can use Azure Front Door or CloudFlare to manage traffic and then swap the DNS. I tested on Staging for a while, then just changed DNS directly. I waited a few hours for traffic to drain off the Windows podcast site and then stopped it. After a day or two of no traffic I deleted it. If I did my job right, none of you noticed the site moved from Windows to Linux, from .NET Core 2.2 to .NET Core 3.1. It should be as fast or faster with no downtime.

Here's a snap of my Azure Portal. As of today, I've moved my home page, my blood sugar management portal, and my podcast site all onto a single Linux App Service Plan. Each is hosted on GitHub and each is deploying automatically with Azure DevOps.

Azure Plan with 3 apps on Linux

Next big migration to the cloud will be this blog which still runs .NET Framework 4.x. I'll blog how the podcast gets checked into GitHub then deployed with Azure DevOps next week.

What cool migrations have YOU done lately, Dear Reader?


Sponsor: Like C#? We do too! That’s why we've developed a fast, smart, cross-platform .NET IDE which gives you even more coding power. Clever code analysis, rich code completion, instant search and navigation, an advanced debugger... With JetBrains Rider, everything you need is at your fingertips. Code C# at the speed of thought on Linux, Mac, or Windows. Try JetBrains Rider today!

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.