Christian Weiss

random thoughts on software development

Simple zero-downtime updates with ASP.NET Core and health checks

Do you use a load balancer that isn’t tightly integrated with your orchestrator and therefore doesn’t know upfront when the orchestrator has to stop an instance of your ASP.NET Core application for an upgrade / a scaling action / a restart?

Does this result in a few failing requests until the load balancer has finally figured out that the instance is gone?

If so, this blog post might be for you!

Using Flutter flavors to separate the DEV and LIVE environment

These are the requirements for our app:

  • Our Flutter app should target iOS and Android.
  • We want a DEV version and a LIVE version of our app, each targeting a different API URL.
  • Developers should never have to manually change any code to switch between the environments.
  • We want to be able to have the DEV app and the LIVE app installed on the same device at the same time.

The best way to solve these requirements in Flutter is to use flavors. There are also some other tutorials for this linked on the official Flutter docs which might be helpful.

The code for this guide is stored on GitHub and changes for each section are separate commits that are linked in the section below.

Find missing projects with PowerShell

In my last post, I showed you a C# script for finding projects which are not part of a SLN-file. Since having to compile it is a bit of an overhead, I decided to migrate this code to a powershell script, which you can find here: ProjectsMissingInSolution.ps1

Find projects which are missing in your "All Projects" solution

Do you use a Visual Studio solution which contains all of your projects to do daily builds? If you have lots of projects and if many people are involved it’s very likely that somebody forgets to add his project to this solution. This small program helps you by showing you all csproj-files that are not part of your solution file! 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 class Program { static void Main(string[] args) { // Parameters string baseFolder = @"C:\path\to\solution\"; string slnFile = "AllProjects.

Feature Folders: Controllers and Views

The first step in our process to a better folder structure for our MVC projects is to make sure, MVC can resolve our Controllers and Views. This is our target structure:

  • (Project Root)
    • Areas
      • (AreaName)
        • (FeatureName)
          • (FeatureName)Controller.cs
          • Index.cshtml
          • Edit.cshtml
        • … (other features)
        • Shared
          • … (area specific shared views like EditorTemplates, Layout-pages, …)
      • … (other areas)
      • Shared
        • … (area independent shared views like EditorTemplates, Layout-pages, …)
    • Features
      • (Feature2Name)
        • (Feature2Name)Controller.cs
        • Index.cshtml
        • Edit.cshtml
      • … (other features)
      • Shared
        • … (feature independent shared views like EditorTemplates, Layout-pages, …)

Of course, if you don’t want to use “areas” you only need the “Features” folder in your project. This also means, that if you move to this new structure, you can completely remove the old “Controllers” and “Views” folders.

Introducing the ASP.NET MVC “Feature Folders” Project Structure

What’s the problem with the default ASP.NET MVC folder structure?

Which of these requirements is more common?

  • Change something in every view, controller or model of your project
  • Add a new field to your model X, show this field to the user, make it editable, the value must be validated against some fancy rules, …

I guess we are on the same page if we see the second one as more common. I would go as far as to say that if you have the first requirement you’re either working on a major relaunch or you’re not using layout pages, css, abstract classes, [insert random reusability gadget here] correctly.