| Sep | OCT | Nov |
| 14 | ||
| 2019 | 2020 | 2021 |
COLLECTED BY
Collection: Outlinks From Tweets
I have been running this https://hanselman.com/blog for almost 20 years. Like coming up on 19 I believe.
Recently it moved from being:
●a 13(?) year old .NET Framework app called DasBlog running on ASP.NET and a Windows Server on real metal hardware
to
●a fresh and new .NET Core app app forked and improved by Mark Downie https://github.com/poppastring/dasblog-core and running under Linux on Azure!
Finally. This blog, the main site, and the podcast site are all running on Azure Web Apps, built in Azure DevOps, and managed by Azure Front Door and watched by Application Insights. Yes I pay for it with cash, I have no unlimited free Azure credits other than my $100 MSDN account.
Mark and I have been pairing on this for months and having a wonderful time. In fact, it's been about a year since this started.
Moving this blog is a significant achievement for a number of reasons, IMHO.
●If we did it right:
●you didn't notice anything
●The URLs look cooler.
●We broke nothing in SEO.
●Perf is better.
●Before I could deploy the site a few times a year, and was afraid of it. Yesterday I deployed 11 times.
●It was .NET 1.1, then 2.0, then 3.5, then 4.0, then stuck for 8 years.
●It ran on a real Windows Server 2008 machine (no VM) at Sherweb who has been a great partner for years. Extremely reliable hosting!
●Now it's on Azure under Linux
●We upgraded the ASP.NET WebForms app to ASP.NET Core with Mark's genius idea of splitting the app responsibilities such that the original DasBlog blog templating language could be converted to simple Razor pages and we could use ASP.NET TagHelpers to replace WebForms controls.
●This allowed me to port my template over in a day with minimal changes.
●Once it compiled under .NET Core it was easy to move it from Windows to Linux and testing in WSL first.
●We then just moved the other dependent projects to .NET Standard 2 and compiled the while thing as a .NET Core 3.1 LTS (Long Term Support) app. In fact, scroll down to the VERY bottom of this page and you can see what version we're on.
●I set up CI/CD for the main site hanselman.com, this blog, and hanselminutes.com.
There are 3 sites now, all behind a reverse proxy from Azure Front Door to handle SSL, Firewalls, and more.
Next steps? Keep it running, watch for errors, 5xx and 4xx and make small incremental changes. The pages are still heavy, while ASP.NET has server response time under 20ms, there's still 2 sec of JavaScript and bunch of old crap to clean up. I've also got two decades of links, so I'm fixing 404s as they are reported or they show up in Application Insights. I made a Dashboard here:
I'm going spend the next month or so blogging about the process and experience in as much detail as I can.
Here's some articles I've already written on the subject:
●Real World Cloud Migrations: Moving a 17 year old series of sites from bare metal to Azure
●Dealing with Application Base URLs and Razor link generation while hosting ASP.NET web apps behind Reverse Proxies
●Updating an ASP.NET Core 2.2 Web Site to .NET Core 3.1 LTS
●Moving an ASP.NET Core from Azure App Service on Windows to Linux by testing in WSL and Docker first
If you find any issues with this blog like
●Broken links and 404s where you wouldn't expect them
●Broken images, zero byte images, giant images
●General oddness
Please file them here https://github.com/shanselman/hanselman.com-bugs and let me know!
Oh, and please subscribe to my YouTube and tell your friends. It's lovely.
About Newsletter
Hosting By
Comment on this post [12]
Share on TwitterorFacebook or use the
Permalink
![image[3]](http://web.archive.org/web/20201014013001im_/https://hanselmanblogcontent.azureedge.net/Windows-Live-Writer/52a307008943_A4F2/image%5B3%5D_3.png "image[3]")
Hayden Barnes from Canonical, the folks that work on Ubuntu (lovely blog, check out it) had a great tweet where he recommended using the Windows Task Scheduler (think of it as a graphical cron job manager) to keep your WSL Linux instances up to date.
There's a few things to unpack here to get into the details.
First, if you run wsl --list -v you'll see all the WSL Linux Instances on your machine.
> wsl --list -vYou can I see I have a few. I spend most of my time in the Ubuntu instances, but I also occasionally drop into the kali-linux and WLinux instances. If I'm using LTS (long term support) distros then there's minimal risk (my opinion) in "apt get update" and "apt get upgrade"-ing them every week or so. I could even do it unattended. I could set up a Task Scheduler and make an "on login" task or a weekly task that calls wsl.exe and passes in -d for distro, along with the name of the distro, run as root with -u and -e for the command. For example:
NAME STATE VERSION
* Ubuntu-18.04 Running 2
kali-linux Stopped 1
Alpine Stopped 1
Ubuntu-20.04 Stopped 2
WLinux Running 2
docker-desktop-data Stopped 2
docker-desktop Stopped 2
wsl -d "Wlinux" -u root -e apt updateSince I have several WSL instances, I could also make a "updateall.cmd" or .bat or .ps1 script and run them occasionally to keep them all updated on my own. Just change the -d and include the name of each distro. One could imagine a group policy as well for large enterprises to do the same thing for developers using a custom or managed WSL instance. You would not want to update or mess with the docker- managed WSL instances above as they exist only to run your Docker Desktop-managed containers. Leave that to Docker to manage. It's a whole new world out there, and I'm loving how I can move easily between multiple Linuxes on Windows 10. Check out my YouTube on WSL2 and please subscribe over there.
wsl -d "Wlinux" -u root -e apt upgrade -y
About Newsletter
Hosting By
Comment on this post [7]
Share on TwitterorFacebook or use the
Permalink
But it's command-line autocompletion that brings me the most joy!
●git ch<TAB> -> git checkout st<TAB> -> git checkout staging
●dotnet bu<TAB> -> dotnet build
●dotnet --list-s<TAB> -> dotnet --list-sdks
●winget in<TAB> -> winget install -> winget install WinDi<TAB> -> winget install WinDirStat
Once you have successfully tab'ed you way to glory it's hard to stop. With PowerShell and its cousins this is made possible with Register-ArgumentCompleter. Here's what it looks like for the dotnet CLI.
# PowerShell parameter completion shim for the dotnet CLILooks like a lot, but the only part that matters is that when it sees the command "dotnet" and some partial text and the user presses TAB, it will call "dotnet complete" passing in the cursorPosition and the wordToComplete. NOTE: If you understand how this works, you can easily make your own Argument Completer for those utilities that you use all the time at work! You can make them for the folks at work who use your utilities! You never actually see this call to "dotnet complete." You just see yourself typing dotnet bui<TAB> and getting a series of choices to tab through! Here's what happens behind the scenes:
Register-ArgumentCompleter -Native -CommandName dotnet -ScriptBlock {
param($commandName, $wordToComplete, $cursorPosition)
dotnet complete --position $cursorPosition "$wordToComplete" | ForEach-Object {
[System.Management.Automation.CompletionResult]::new($_, $_, 'ParameterValue', $_)
}
}
>dotnet complete --position 3 buiYou can add these to your $profile. Usually I run 'notepad $profile" at the command line and it will autocreate the correct file in the correct location. This is a super powerful pattern! You can get autocomplete in Git in PowerShell with PoshGit as well as in WinGet! What are some more obscure autocompletes that you have added to your PowerShell profile? ACTION: Finally, please take a moment and subscribe to my YouTube or head over to http://computerstufftheydidntteachyou.com and explore! I'd love to hit 100k subs over there. I heard they give snacks.
build
build-server
msbuild
About Newsletter
Hosting By
Comment on this post [13]
Share on TwitterorFacebook or use the
Permalink
I'll then click the dropdown, hold ALT, and click on the Visual Studio Developer Command Prompt that I've added to the menu. I'm doing this while Ubuntu is the focused pane.
And the result:
Now you can see the VS2019 prompt in the lower left corner. With hotkeys I can control where panes open.
I can even navigate between pans with the ALT key and my arrow keys! Even better, SHIFT+ALT and the arrow keys will resize them!
Go spend some time learning about Panes in Windows Terminal and let me know how it goes for you! It's gonna make your command line life so much better!
ACTION: Finally, please take a moment and subscribe to my YouTube or head over to http://computerstufftheydidntteachyou.com and explore! I'd love to hit 100k subs over there. I heard they give snacks.
About Newsletter
Hosting By
Comment on this post [4]
Share on TwitterorFacebook or use the
Permalink
dotnet tool install -g dotnet-monitor --add-source https://dnceng.pkgs.visualstudio.com/public/_packaging/dotnet5-transport/nuget/v3/index.json --version 5.0.0-preview.*You then just run it along side your project or running process.
dotnet monitor collectThe developer blog on dotnet monitor shows you how you can share a volume mount between your application container and a container running dotnet monitor if you like. If you're in k8s (Kubernetes) you should run dotnet monitor as a sidecar to your container within the same pod. It'll start up and you can talk to dotnet monitor with curl, wget, and pipe through jq and hit localhost:52323/processes to get a list of .NET Core processes it can think about. NOTE: If you are running this locally and get auto redirected to HTTPS then you may have a cached HSTS policy for localhost from other work. Head over to edge://net-internals/#hsts (or chrome://) and scroll to the bottom and delete the Domain Security Policies for localhost. Now I can curl and see the output. I have my podcast on the left pane in Windows Terminal, dotnet monitor collect in the upper right, and the output lower right.
Once I figure out my process id (PID) - which will be automatic within a container as there will only be one - I can explore any of these local endpoints:
●
/processes
●/dump/{pid?}
●/gcdump/{pid?}
●/trace/{pid?}
●/logs/{pid?}
●/metrics
If you are getting the logs, you'll get a never ending text/event-stream in your browser. I'd recommend you "curl" to see this at the command line.
You can also get momentary traces, collect a nettrace file and analyze it in Visual Studio, PerfView or other tools.
The dotnet monitor is experimental, but if you're digging it, head over to the dotnet/diagnostics GitHub and show some support.
About Newsletter
Hosting By
Comment on this post [4]
Share on TwitterorFacebook or use the
Permalink
<< Older Posts
Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.