I’ve been building a microservices template as part of my master’s thesis. It’s using GitHub for code hosting and Microsoft Azure for hosting the resources. One key requirement of my template is to use Managed identities for Azure everywhere and not use any secrets when connecting to dependent resources.

Managed identities are a great feature and very easy to use for built-in workloads like VMs, Azure Container Apps, App Services. However, until recently, managed identities could not be used for non-native workloads like GitHub Actions. We had to use an Azure AD app registration instead and store its credentials (including a CLIENT_SECRET) as GitHub secrets. With the introduction of workload identity federation for app registrations, it was then possible to configure a trust relationship between GitHub and Azure that allows the GitHub Actions to authenticate to Azure without the need for providing a CLIENT_SECRET. This would have already solved my requirement for not needing any secrets, but the problem is, that creating an Azure AD app registration requires elevated permissions and therefore often can’t easily be done by regular developers.

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!

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.

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

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!

class Program
{
    static void Main(string[] args)
    {
        // Parameters
        string baseFolder = @"C:\path\to\solution\";
        string slnFile = "AllProjects.sln";
        string outputFile = "MissingProjects.txt";

        string slnContent = File.ReadAllText(Path.Combine(baseFolder, slnFile));

        string[] projectFiles = Directory.GetFiles(baseFolder, "*.csproj", SearchOption.AllDirectories);

        List<string> missingProjects = projectFiles
            .Where(fullPath => slnContent.IndexOf(fullPath.Replace(baseFolder, ""), StringComparison.OrdinalIgnoreCase) < 0)
            .ToList();

        File.WriteAllLines(outputFile, missingProjects);

        Console.WriteLine("Projects missing in solution: " + missingProjects.Count);
        Console.WriteLine("Details: " + outputFile);
        Console.ReadLine();
    }
}

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.