• The documentation and training links often reference Foundry (Classic)

• But the portal youre using today might show Foundry (New)

• And the way you create projects and resources looks slightly different

This blog is a practical guide on what changed, how Classic and New relate, and what youll actually see in your Azure subscription.

1. What is Microsoft Foundry?

At a high level, Microsoft Foundry is Azures unified platform for building, deploying and governing modern AI applicationsespecially those built around agents, AI workflows, evaluations, tools, and observability.

Instead of stitching together isolated services for model hosting, agent orchestration, monitoring, and governance, Foundry brings all of these capabilities into a single experience.

Think of it as Azures all-in-one platform for AI development.

2. Project Types in Microsoft Foundry

Before comparing Classic and New Foundry portals, its important to get one thing right:

Foundry has two project types.

1. Hub-based Projects (older model)

2. Foundry Projects (modern unified model)

Everything elseClassic vs New portalsis essentially different UX layers sitting on top of these project types.

Hub-based Projects (Older Model)

This is the pre-Foundry architecture, built around:

• Azure AI Hub

• Azure AI Project

• Supporting resources (storage accounts, managed identities, network components, etc.)

This was the default model before Foundry unified the platform.
As a result, Foundry (Classic) continued to support and create these hub-based setups.

When you create a hub-based project, Azure provisions:

• Azure AI Hub resource

• Azure AI Project resource

Youll still see references such as:

• Azure AI Hub

• AI Project

• Project under a hub

Most older tutorials, Prompt Flow documentation, and Learn modules are based on this model. Also, Prompt Flow is currently supported only in hub-based projects.

Foundry Classic = supporting the old Hub-based architecture.

Foundry Projects (Modern Model)

This is the recommended, simplified, and future-facing project type.

A Foundry project includes:

• Foundry resource

• Foundry Project resource

There is no hub in this model.

This architecture simplifies:

• Access control

• Monitoring & observability

• Resource management

• Agent workflows

• Tooling integrations

• Lifecycle operations

When you create a Foundry project, Azure provisions:

• Foundry resource

• Foundry Project resource

Foundry New = hub-less, modern, and the future of the platform.

3. Two Portals One platform

There are two Foundry portal experiences, but both operate on the same platform.

Foundry (Classic)

This is the older UI, and most existing training content still references it.

• Lets you create both Hub-based Projects and Foundry Projects

• Still widely used because of older documentation

• Provides the UI that hub-based resources depend on

Foundry (New)

This is the modern experience with a cleaner UI and a project model aligned to the future of Azure AI development.

• Only allows creation of Foundry Projects

• Streamlined navigation

• Better integrations for agents, tools, workflows and evaluations

• A unified structure without hubs

In the Foundry portal, you can switch between Classic and New using the toggle at the top:

The official docs also include a Version toggle for Classic vs Newvery useful when your UI doesnt match the tutorial:

4. Foundry Classic vs Foundry New Side-by-Side

Now that weve seen both portals, heres a simple comparison to keep in mind:

When in doubt:

• If youre starting something new, use Foundry (New) with a Foundry Project.

• If youre following an older tutorial or managing an existing hub-based environment, you may still need Foundry (Classic).

5. Migration & Following Training Material

If your team is still running on hub-based projects, Microsoft supports migrating to the modern Foundry Project model. The migration involves moving:

• Model deployments

• Data connections

• Tools & workflows

• Identity & access policies

Depending on how the old project was structured, some steps may be manual.

Tips when learning or following training modules

• If a tutorial shows Classic, just switch the docs to the matching version.

• If youre creating something new, always choose a Foundry Project in the new portal.

• Prompt flow is currently supported only in Hub based projects.

• Expect naming confusion initiallyAI Hub, Foundry, AI Project, Foundry Projectbecause the platform has been evolving.

6. Final Thoughts

The difference between Foundry (New) and Foundry (Classic) is not about two different products.
Its about one platform moving from an older Hub-based architecture to a cleaner, unified project model.

To keep it simple in your mind:

• Foundry (New) + Foundry Project
  Modern, streamlined, and the recommended default for all new scenarios

• Foundry (Classic) + Hub-based Projects
  Older architecture, still supported, primarily used when following legacy tutorials or working with older deployments

As the Azure AI ecosystem continues to evolve, the Foundry Project model is where Microsoft is investingso thats where youll want to be.

In this blog, we'll explore the performance of ASP.NET Core Web API by creating a simple response API using ASP.NET Core 8.0. The goal of this article is not to test real-world performance scenarios but to see how quickly we can process the simplest request through the ASP.NET Core pipeline using k6 tests, both locally and on Azure App Service with B2 and P2V3 plans.

Setting up the test environment

Before we dive into testing, let's set up the test environment. We will create two types of APIs using ASP.NET Core:

1. Minimal API: A lightweight approach introduced in .NET 6 that allows for a more streamlined and concise way to define endpoints.

2. Controller-based API: The traditional approach, providing a structured way to build APIs.

Create the ASP.NET Core Project

Create the project using either the dotnet new webapi -o "Web API Performance" command or the Visual Studio GUI.

The .csproj would be:

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
    <RootNamespace>Web_API_Performance</RootNamespace>
  </PropertyGroup>
</Project>

Define the minimal API in the Program.cs file:

// Program.cs
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddControllers();

var app = builder.Build();

app.UseHttpsRedirection();
app.MapControllers();

app.MapGet("/api/hello", () => "Hello, World!");
app.MapGet("/api/weather", () =>
{
    return new { Temperature = "20C", Condition = "Sunny" };
});

app.Run();

Define the controller in the Controllers folder:

// SimpleController.cs
using Microsoft.AspNetCore.Mvc;

namespace Web_API_Performance.Controllers
{
    [ApiController]
    [Route("api/[controller]")]
    public class SimpleController : ControllerBase
    {
        [HttpGet("hello")]
        public string Get()
        {
            return "Hello, World!";
        }

        [HttpGet("weather")]
        public IActionResult GetWeather()
        {
            var weather = new
            {
                Temperature = "20C",
                Condition = "Sunny"
            };
            return Ok(weather);
        }
    }
}

This setup will yield four APIs:

• Minimal APIs: /api/hello and /api/weather

• Controller APIs: /api/simple/hello and /api/simple/weather

Deploying to Azure App Service

Once the APIs are set up and running locally, the next step is to deploy them to Azure App Service. This will allow us to test the performance of our APIs on different Azure App Service Plan SKUs.

We'll create a web app with the runtime stack .NET 8 (LTS) in Azure and deploy our web API to the Central India region.

The deployed web app now contains the 4 APIs ready & running.

Azure App Service Plan SKUs for Testing

We will test the performance of our APIs on the following Azure App Service Plan SKUs:

• Basic B2 - 2 core vCPU | 3.5 GB RAM

• Premium v3 P2V3 - 4 core vCPU | 16 GB RAM

Unveiling Performance with k6

To effectively measure the performance of our basic APIs, we will use k6, a modern load testing tool, running tests locally and on the deployed Azure App Service. The results will be exported to a Grafana cloud instance for visual representation.

The k6 test script would be:

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  vus: 1,
  duration: '2m'
};

export default function() {
  const res1 = http.get('https://<url>/api/hello', {
    tags: { name: '<Local/Deployed> - Minimal hello' },
  });
  const res2 = http.get('https://<url>/api/weather', {
    tags: { name: '<Local/Deployed> - Minimal weather' },
  });
  const res3 = http.get('https://<url>/api/simple/hello', {
    tags: { name: '<Local/Deployed> - Controller hello' },
  });
  const res4 = http.get('https://<url>/api/simple/hello', {
    tags: { name: '<Local/Deployed> - Controller weather' },
  });

  check(res1, {
    'status is 200 of <Local/Deployed> minimal hello': (r) => r.status === 200,
  })
  check(res2, {
    'status is 200 of <Local/Deployed> minimal weather': (r) => r.status === 200,
  })
  check(res3, {
    'status is 200 of <Local/Deployed> controller hello': (r) => r.status === 200,
  })
  check(res4, {
    'status is 200 of <Local/Deployed> controller weather': (r) => r.status === 200,
  })
}

Running the Test Locally:

Running the ASP.NET Web API application in Release configuration on a local machine with an 11th Gen Intel(R) Core(TM) i7 processor & 32GB RAM, and testing it using k6 with 1 VUS for 2 mins yielded the following result:

The P95 for both minimal and controller APIs are ~0.69ms; that's sub-millisecond execution locally. Total requests made were 371K in 2-minute test duration with Peak RPS being ~4K req/s.

Running the Test on Basic B2 plan:

Running the Web API on the Azure App Service Basic B2 plan and testing it using k6 with 1 VU for 2 minutes yielded the following results:

The P95 for both minimal and controller APIs is ~26ms when deployed to Azure App Service. A total of 5.5K requests were made during the 2-minute test duration, with a peak RPS of 47.3 req/s.

Azure Speed Test shows an average latency of 23ms to 26ms from the local machine to the deployed Azure Central India data center which justifies the time taken by the API. In summary, the deployed instance is also performing efficiently, with response time close to or under one millisecond, excluding network latency.

Running the Test on Premium v3 P2v3 plan:

Running the Web API on the Azure App Service Premium P2v3 plan and testing it using k6 with 1 VU for 2 minutes yielded the following result:

The P95 for both minimal and controller APIs are ~26ms when deployed to Azure App Service P2V3 plan. Total requests made were 5.7K in the 2-minute test duration with Peak RPS being 50 req/s. The results are nearly indistinguishable, with minor discrepancies due to network latency between the test machine and the datacenter.

Analyzing the Results

After running the tests and gathering the performance metrics, several points stand out:

• Minimal vs. Controller APIs: In .NET 8, there's negligible execution time disparity between the two.

• Local Performance: Sub-millisecond response time underscores ASP.NET Core's efficiency.

• Azure Realms: Network latency emerges as the primary factor, resulting in comparable performance across App Service Plan SKUs.

Summary

Our tests on basic ASP.NET Web APIs present a clear picture: both minimal and controller-based APIs demonstrate impressive performance with sub-millisecond response time in a local environment. However, when deployed to Azure, performance differences emerge due to network latency and the chosen App Service Plan's capabilities. The Azure App Service Premium tier offers marginally better performance than the Basic tier, but network latency remains a critical factor.

It's important to note that this test was conducted to measure basic performance characteristics with very simple APIs, not real-world scenarios. As a result, there isn't much difference in performance between the Basic B2 and Premium P2V3 tiers. However, in real-world applications, where higher processing power is required, the Premium tier will definitely outperform.

These insights highlight not only the importance of considering both infrastructure and network conditions when optimizing API performance but also demonstrate how efficiently ASP.NET Core Web API can handle requests.

In this article, we aim to determine the performance of different loops across various .NET target frameworks (.NET Framework 4.7.2, .NET Core 3.1, .NET 6.0, .NET 8.0, .NET 9.0-preview-4) when iterating over a List of strings.

Setup

To compare list loop performance, we will iterate over 10 million strings using a List<string>. To ensure consistency, we will generate the dataset using C#'s Random method with the same "seed" value.

We will utilize the BenchmarkDotNet library to benchmark the performance of various loops. This is a widely used library for benchmarking, even by the dotnet product teams.

Here is the snippet of our benchmark's "GlobalSetup" :

private readonly List<string> list = new List<string>();

// 10 million elements
private readonly int size = 10000000;

[GlobalSetup]
public void Setup()
{
    var random = new Random(580);
    for (int i = 0; i < size; i++)
    {
        list.Add(random.Next().ToString());
    }
}

The Loops

We will test the following looping methods on the list of strings:

• for loop

• foreach loop

• List.ForEach loop

• while loop

• do-while loop

Additionally, we will compare performance across these dotnet versions:

• .NET Framework 4.7.2

• .NET Core 3.1

• .NET 6.0

• .NET 8.0

• .NET 9.0-preview-4

Here is the benchmark test class:

[SimpleJob(RuntimeMoniker.Net472, baseline: true)]
[SimpleJob(RuntimeMoniker.NetCoreApp31)]
[SimpleJob(RuntimeMoniker.Net60)]
[SimpleJob(RuntimeMoniker.Net80)]
[SimpleJob(RuntimeMoniker.Net90)]
[MemoryDiagnoser]
public class ListLoopingPerformanceBenchmark
{
    private readonly List<string> list = new List<string>();

    // 10 million elements
    private readonly int size = 10_000_000;

    [GlobalSetup]
    public void Setup()
    {
        var random = new Random(580);
        for (int i = 0; i < size; i++)
        {
            list.Add(random.Next().ToString());
        }
    }

    [Benchmark(Description = "for")]
    public string For()
    {
        var result = string.Empty;
        var size = list.Count;
        for (int i = 0; i < size; i++)
        {
            result = list[i];
        }
        return result;
    }

    [Benchmark(Description = "foreach")]
    public string Foreach()
    {
        var result = string.Empty;
        foreach (var item in list)
        {
            result = item;
        }
        return result;
    }

    [Benchmark(Description = "ForEach")]
    public string ForEach()
    {
        var result = string.Empty;
        list.ForEach(item => result = item);
        return result;
    }

    [Benchmark(Description = "while")]
    public string While()
    {
        var result = string.Empty;
        int i = 0;
        int size = list.Count;
        while (i < size)
        {
            result = list[i];
            i++;
        }
        return result;
    }

    [Benchmark(Description = "do-while")]
    public string DoWhile()
    {
        var result = string.Empty;
        int i = 0;
        int size = list.Count;
        do
        {
            result = list[i];
            i++;
        } while (i < size);
        return result;
    }
}

For the complete code setup, you can visit GitHub repository.

Results

Based on the benchmarking setup, the results vary across different .NET versions, showcasing improvements over time. Here's a summary:

• The for loop shows significant performance improvements from .NET Framework 4.7.2 to .NET 9.0-preview, with .NET 9.0-preview being 1.28x faster than the baseline.

• The foreach loop exhibits substantial gains, especially from .NET Framework 4.7.2 to .NET 9.0-preview, being 3.82x faster.

• The List.ForEach method is generally slower compared to other loops, though it shows some improvements in .NET 9.0-preview.

• Both while and do-while loops demonstrate similar performance enhancements, with .NET 9.0-preview versions being approximately 1.30x faster than .NET Framework 4.7.2.

Bonus high performance looping with latest .NET

.NET 5 introduced CollectionsMarshal.AsSpan<T>, which provides direct access to the underlying array of a list as a span, providing a more efficient way to work with list elements. However, this should be used with caution, as modifying the list during iteration can lead to unexpected behavior.

Let's test the benchmark for this with different loop sizes of 1 million and 10 million records and see if it provides better results than looping over the list directly.

[SimpleJob(RuntimeMoniker.Net60, baseline: true)]
[SimpleJob(RuntimeMoniker.Net80)]
[SimpleJob(RuntimeMoniker.Net90)]
[MemoryDiagnoser]
public class ListLoopingPerformanceBenchmark
{
    private readonly List<string> list = new List<string>();

    [Params(1_000_000, 10_000_000)]
    public int size;

    [GlobalSetup]
    public void Setup()
    {
        var random = new Random(580);
        for (int i = 0; i < size; i++)
        {
            list.Add(random.Next().ToString());
        }
    }

    // Adding `for` loop as comparision with `span`.
    [Benchmark(Description = "for")]
    public string For()
    {
        var result = string.Empty;
        var size = list.Count;
        for (int i = 0; i < size; i++)
        {
            result = list[i];
        }
        return result;
    }

    [Benchmark]
    public string Span()
    {
        var result = string.Empty;
        int size = list.Count;
        Span<string> span = CollectionsMarshal.AsSpan(list);

        for(var i = 0; i < size; i++)
        {
            result = span[i];
        }
        return result;
    }
}

Running these tests yields the following results for the Span loop:

Findings:

• For smaller data sizes (1,000,000 elements):

  • The span loop in .NET 9.0-preview is almost 1.80x faster than in .NET 6.0 and nearly 1.6x faster when compared to for loop in .NET 9.0-preview.

  • This demonstrates a significant performance gain, making Span loops an attractive choice for handling smaller data sizes efficiently.

  • Do note the time taken to loop the entire list is mere micro seconds.

• For larger data sizes (10,000,000 elements):

  • The Span loop in .NET 9.0-preview is 1.14x faster than in .NET 6.0 and nearly 1.14x faster when compared to for loop in .NET 9.0-preview.

  • Although the improvement is more moderate compared to smaller data sizes, it still shows noticeable performance gains.

• This method should only be used when you understand its implications and there is a clear benefit.

Conclusion

This article explored the performance of different loop constructs in various .NET versions. We observed significant performance improvements over time, particularly from .NET Framework to .NET 9.

Except for the List.ForEach method, the other loop methods perform similarly in terms of time and memory usage in the latest .NET versions. The Span loop using CollectionsMarshal.AsSpan<T> method introduced in .NET 5 can offer substantial performance gains for small and medium data sizes.

However, while the Span loop offers excellent performance, it should be used with understanding of its implications and only when there is a clear benefit. Since the time difference between loops on a list of 10 millions records is very less, choosing the right loop construct should also consider readability, maintainability, and the specific use case requirements. By understanding these performance characteristics, developers can make more informed decisions to optimize their applications effectively.

For the complete code setup and benchmarks, visit GitHub repository.

Happy coding! 🚀

As a best practice, it is recommended to use Azure Managed Identity (often referred to as MSI) whenever possible when connecting to storage accounts and other Azure services. With managed identity, Azure automatically manages secure access to Azure resources without the need for providing explicit credentials in code or configuration.

This article guides you through the process of using managed identity for AzureWebJobsStorage. At a high level, the following steps are required:

1. Enable system-assigned managed identity for the function app.

2. Grant the function's identity access to the storage account.

3. Edit the AzureWebJobsStorage configuration.

Enable system-assigned managed identity for the function app

1. In the Azure portal, navigate to the Azure Function app.

2. Select the Identity option from the menu blade.

3. On the System assigned tab, set the status to "On" and Save it.

   

Grant the function's identity access to the storage account

Create a role assignment granting the system-assigned identity access to the storage account.

1. Navigate to the storage account that was created with the function app.

2. Select Access Control (IAM). You can view and configure who has access to the resources from IAM.

3. Click Add and select Add Role Assignment.

4. Search for the 'Storage Blob Data Owner' role, select it, and click Next.

   

5. On the Members tab, under Assign access to, select Managed Identity.

6. Click Select members to open the identities side panel.

7. Choose the right Subscription, and in the managed identity selector, choose Function App from the System-assigned managed identity category.

   

8. The function app should appear in a list below the input fields. Click on the function app name, and it should now be part of the selected members section. Click Select.

   

9. Back on the Add Role Assignment page, click Review + assign. Review the changes, and then click Review + assign.

   

Edit the 'AzureWebJobsStorage' configuration

Next, update your function app to use the system-assigned identity when connecting to the blob service.

1. Navigate to your function app, and under Settings, select Configuration.

2. Select the Edit button next to the AzureWebJobsStorage application setting.

3. Under Name, change the text from 'AzureWebJobsStorage' to 'AzureWebJobsStorage__accountName' This modified setting instructs the host to use the identity instead of looking for a stored secret. Please note that the new setting uses __ (double underscore), which is a special character in application settings.

4. Under Value, input your storage account name, i.e., replace the connection string with just the storage account name.

   

5. Select OK, and then click on Save > Continue to save your changes.

You have now successfully configured the Azure function to connect to the storage account using managed identity instead of the storage connection string containing credentials.

Final thoughts

In this article, we have looked at the essential steps to fortify the security of your Azure Functions when connecting to the host storage account. By embracing the best practice of utilizing Azure Managed Identity (MSI), we mitigate security risks associated with managing account keys and elevate the overall protection of our applications.

This article used the system-assigned managed identity of the function app to connect to the storage account, but even a user-assigned managed identity can be used while granting necessary access to the function & storage account. The use of Managed Identity streamlines the authentication process, eliminating the need for explicit credentials in your code or configurations.

Take charge of your application's security journey, and let Managed Identity be your trusted companion in the realm of Azure services.

Happy coding and stay secure!

Disabling a function locally

The best way to disable a function while running locally is by using an app setting in the local.settings.json file in the format AzureWebJobs.<FUNCTION_NAME>.Disabled set to true. For example, if you have three functions: ProcessOrder, SendEmailNotification, and GeneratePDFReport, and you want to disable only the SendEmailNotification function, add the following entry to the Values collection in the local.settings.json file:

{
  "IsEncrypted": false,
  "Values": {
    "FUNCTIONS_WORKER_RUNTIME": "dotnet",
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    // The below line disables the 'SendEmailNotification' function
    "AzureWebJobs.SendEmailNotification.Disabled": true
  }
}

While there are other ways to disable functions, these methods can vary depending on the language and runtime version used. Therefore, the application setting mentioned above is the recommended approach for all languages and all runtime versions.

Disabling a function in Azure

To disable a function in a deployed Azure Function App, the same configuration method as mentioned above can be used.

Going by the same example as above, if you have three functions: ProcessOrder, SendEmailNotification, and GeneratePDFReport, and you want to disable only the SendEmailNotification function, navigate to the Configuration tab of your Azure Function App and add a "New Application Setting" with the name AzureWebJobs.SendEmailNotification.Disabled and Value true. If you want to re-enable the function, simply change the value to false

Another option is to use the "Disable" button in the Azure Portal against the function to disable it.

Once the function is disabled, any attempt to invoke it will result in an HTTP 404 Not Found error.

In conclusion, knowing how to disable Azure Functions locally and in the Azure cloud is essential for efficient development and debugging. By leveraging app settings and configuration options, you can selectively disable specific functions, optimizing your workflow and improving overall performance. With this knowledge, you gain control over your function app's behavior, maximizing productivity in your Azure projects.

One of the most commonly used triggers is the Timer trigger. This trigger lets you run your Azure function on a predefined schedule. The schedule is defined via a CRON expression, and in some cases, the scheduled trigger is often hours apart. However, there could be scenarios where you need to run a timer function immediately rather than waiting for the scheduled time. Some of the most common examples include - a code bug that caused many executions to fail, and you want to clear the backlog immediately; or you made changes to the function and want to test immediately instead of waiting, or you have business scenarios that require you to sometimes trigger the timer function manually. One way to do this is to use the CRON expression from a configuration, update the configuration, and restart the Function. But that's clunky and inconvenient. In this article, we will see how to force immediate execution with manual triggering in an Azure Timer Function without changing the CRON expression.

Get the Function's Master Key

To trigger the Timer function manually, you need to get the Function's Master Key. To do this,

1. Navigate to the function app in Azure Portal, select App Keys, and then select the _master key.

2. Copy the key value as this would be used in the next step.

   

Make the HTTP request

To trigger the Timer function manually, make an HTTP POST request in the following form:
https://<function base-url>/admin/functions/<function-name>
with a header key of x-functions-key and the value of _master key copied earlier, and an empty JSON {} request body.

For example, if you have a function named TimerTrigger1 deployed in demoblogfunctions.azurewebsites.net you can trigger it manually with the following request:

POST 
https://demoblogfunctions.azurewebsites.net/admin/functions/TimerTrigger1

Request Headers:
x-functions-key: S5zxMCvMuDvQVegJEEmALUJEiLC1Rlj7Qz3QO_T3IB_vAzFuhlWa2w==
Content-Type: application/json

Request Body:
{}

If the request is sent successfully, you should receive an HTTP status code of 202 Accepted, and the timer function will be triggered immediately.

The function logs, as well as application insights if connected, will also indicate the trigger.

Caution: Due to the elevated permissions in your function app granted by the master key, you should not share this key with third parties or distribute it in an application. The key should only be sent to an HTTPS endpoint.

This approach to immediate execution using the admin APIs is not limited to Timer Trigger and can be used to run any non-HTTP-Triggered azure function by passing in the required input in the request body.

This article covers creating a YAML based PR build validation pipeline for the .Net 5 project and setting build policies in Azure DevOps to ensure all PRs to the master branch are automatically validated using the pipeline and only build validated PRs can be merged.

We will be using a sample Azure DevOps repo having the Getting started ASP.NET Core Web App project running on .Net 5 checked in. The same set of steps can be used for other .Net 5 projects as well.

This article will perform the following on the Azure DevOps project:

• Setup PR Build validation YAML pipeline
• Add the pipeline to Azure DevOps pipelines
• Add build validation policy for master/main branch
• Create PRs & test it

Setup PR Build validation pipeline

The first step is to set up a PR build validation yaml pipeline. I usually prefer to keep the pull request pipelines in the deployment\devops-pipelines\pull-requests folder from the root of the repository.

Create a WebApplication-pr.yml file (any file name that suits your project) in the deployment\devops-pipelines\pull-requests folder with the following content to create the PR pipeline which restores, builds, and tests the .Net 5 project code.

# File: WebApplication-pr.yml
# Description:
#   PR build pipeline for WebApplication solution.
#   This job performs the following activities:
#     - Restores
#     - Builds
#     - Tests projects & collects code coverage

trigger: none

variables:
  # Working Directory
  workingDirectory: '$(System.DefaultWorkingDirectory)/'
  buildPlatform: 'Any CPU'
  buildConfiguration: 'Release'

stages:
  - stage: Build
    displayName: Build stage

    jobs:
      - job: Build
        displayName: Build
        pool:
          name: 'Azure Pipelines'
          vmImage: 'windows-latest'

        steps:
          # Install .Net 5.0
          - task: UseDotNet@2
            displayName: 'Install .NET 5.0 SDK'
            inputs:
              packageType: 'sdk'
              version: '5.0.x'

          # Restore dependencies
          - task: DotNetCoreCLI@2
            displayName: 'Restore NuGet packages'
            inputs:
              command: 'restore'
              projects: '**\WebApplication.sln'
              feedsToUse: 'select'
              includeNuGetOrg: true
              noCache: false

          # Build the solution
          - task: DotNetCoreCLI@2
            displayName: 'Build solution file'
            inputs:
              command: 'build'
              projects: '**\WebApplication.sln'
              arguments: '--configuration $(BuildConfiguration)'

          # Run the tests and collect code coverage
          - task: DotNetCoreCLI@2
            displayName: 'Test .Net Core Project in code'
            inputs:
              command: 'test'
              projects: |
                src\Tests\**\*.csproj
              publishTestResults: true
              arguments: '--configuration $(BuildConfiguration) --collect:"Code coverage"'

The pipeline does 4 tasks in the Build stage - i.e.,

• Install .Net 5.0 in the agent
• Restore dependencies
• Build the solution
• Run the tests and collect code coverage

This is the bare minimum PR pipeline, but you could add in other tasks as required.

The above DevOps pipeline doesn't have any trigger defined as we will use the Azure DevOps Build Validation policies for triggering it. Also, the agent being used is a Microsoft Hosted Agent, in case your choice of agent is different, please change the pool in the build job.

Check-in the above pipeline to your code repository, and let's trigger it from Azure DevOps so that we can test the pipeline.

Add the pipeline to Azure DevOps pipelines

To add the above checked-in yaml pipeline to Azure DevOps pipelines,

1. Navigate to 'Pipelines' in Azure DevOps. Select 'Create Pipeline' or 'New Pipeline' to create a new pipeline.
2. Select the code repo.
3. Click on 'Existing Azure Pipelines YAML file' from the pipeline configuration page.
4. Add in the YAML pipeline file path and click 'Continue'
5. Click on 'Run' to trigger the pipeline.
6. This will queue the build and the build will be completed in some time.
7. Navigate back and rename the pipeline to a more meaningful one, so that it's clear to identify.

Note: Please run the PR pipeline at least once before proceeding to the next step, as only in that case the pipeline will be visible on the Build Validation policy settings page.

Add build validation policy for master/main branch

Now that you have the PR pipeline ready and executed at least once, it's time to update the build validation policy for the master/main branch so that subsequent PRs will result in the pipeline being executed and completed successfully for the PR to be merged.

To add the build validation policy,

1. Navigate to 'Branches' under 'Repos' in Azure DevOps. Click on the kebab menu icon against the master/main branch and select 'Branch Policies' from the context menu.
2. In the branch policies settings page, Add a 'Build Validation' policy. Select the PR pipeline that ran earlier from the dropdown of the policy page. Review other settings and click 'Save' to enable the build validation.
3. Build Validation policy is now in place and future PRs will require this build validation to pass i.e. the PR pipeline to run successfully.

Create PRs & test it

Create a Pull Request and the pipeline should get triggered automatically as part of the 'Required' checks.

In case of build-failure, the Pull Request won't be allowed to merge.

That's it!! Azure DevOps Pull Request build validation pipeline has been set up for .Net 5 project and this policy plus pipeline will ensure only successfully building code is merged to master/main branch.

Often when you are developing REST APIs, one of the tough conversations to have with the consumers of your API (web client, mobile app, other 3rd parties, etc.) is defining the way your API would specify errors. Now, this is a crucial piece of design as depending on it the client/consumer will design their part of showing errors to the end-users. For example, imagine an API that allows customers to book movie tickets online and this call returns a Bad request (400) response without any other additional info. The user doesn't understand why the Client UI is showing an error and the Client UI doesn't know why the API has failed.

Many people have different designs for specifying the errors in the API response - some just return status code without any response message, while some describe a simple text message in the body and others specify custom JSON schema for specifying the errors.

Due to this, the Internet Engineering Task Force (IETF) proposed the "Problem Details for HTTP APIs" specification in March 2016. As per it,

"Problem Details" is a way to carry machine-readable details of errors in a HTTP response to avoid the need to define new error response formats for HTTP APIs.

A simple example of HTTP response of JSON problem details is :

HTTP/1.1 400 Bad Request
Content-Type: application/problem+json

{
    "type": "https://tools.ietf.org/html/rfc7231#section-6.5.1",
    "title": "One or more validation errors occurred.",
    "status": 400,
    "errors": {
        "Id": [
            "The Id field is required."
        ],
        "Fact": [
            "The Fact field is required."
        ]
    }
}

The format of the message is application/problem+json or application/problem+xml media type and the response body must at bare minimum contain the below fields:

• type : A URI that defines the problem detail type.
• title : A title that summarizes the problem.
• status : HTTP status code.

We can extend the problem details with additional properties, for example, the above error message defined "errors" to communicate additional information to the client.

Problem details in ASP.NET Core

In ASP.NET Core 2.1, the team added ProblemDetails class to support problem details model. And in ASP.NET Core 3.0, the ControllerBase.Problem method was added to produce a ProblemDetails response from controller action methods.

In the rest of the article, we will look at handling different error types from ASP.NET Core and how to use the inbuilt functionality already provided to specify the errors in ProblemDetails response format.
We will look at specifying error responses for :

• 400 Bad Request
• 404 Not Found
• 500 Internal Server Error

We will primarily be using the ControllerBase.Problem method to specify errors manually and leaving it to the ASP.NET Core to generate for others.

400 Bad Request

We have 2 scenarios here: Failed model validations using DataAnnotations and Custom bad request

• Failed model validations using DataAnnotations: In this case, you don't need to do any additional work. ASP.NET Core will take care of it for you, given that you are using the [ApiController] attribute to the API controller and DataAnnotations for validating the model.

  In the above example, we have a POST API and the input data model is validated using the Required attribute of the DataAnnotations class. When this API is called without passing in the required parameters of the model, a 400-Bad Request in the ProblemDetails format is generated.

• Custom bad request: Maybe the business rule failed or some other logic check failed and you need to return 400-Bad Request. In this case, you can use this.Problem(detail, statusCode: 400) inside the Controller to return the error in problem details format.

  In the above example code, we are sending 400 from the controller using the Problem method when the business logic fails. Hitting the API with an invalid request will result in a 400-Bad Request in the ProblemDetails format.

404 Not Found

For the 404 wherein the route didn't match, there isn't much you can do, but for scenarios where you want to return "Not Found" when data for the specified Id is not found, etc.; using the NotFound() method in Controller will return the 404 in Problem Details format.

In the above example code, we are returning NotFound() from the controller when the result is not found for the specified Id. Hitting the API with an invalid Id will result in 404-Not Found in the ProblemDetails format.

500 Internal Server Error

In case of 500 Internal server error, you don't want to expose off any exception object details as it will contain crucial code and system-related information; but should still adhere to the Problem Details format by giving a vague "An error occurred while processing your request." error message to the API caller. In this case, you can use this.Problem() inside the Controller to return the error in problem details format with the default 500 error message and status code. In some very exceptional cases wherein you would like to send custom messages for the exception, use the this.Problem(customErrorMessage) inside the Controller.

Hitting the above API which might result in some exceptions will return the response in the right format.

Summary

Problem Details standard is proposed by IETF and has been around for quite some time, but still, its usage or adherence is very low. Often people reinvent the wheel or follow different approaches while specifying errors in the Web API responses. In this article, we looked at the ProblemDetails specification and also using the Problem() method in the ControllerBase of ASP.Net Core application to return errors in this standard format.

1. Navigate to the Solution Explorer of your project and
   Right-click on the ASP.NET project -> Select Add -> Click Docker Support
2. Choose the Target OS where the docker image will run Windows / Linux, and click OK

3. Visual Studio will create a Dockerfile for you, which specifies how to create the container image for your ASP.NET Core app project.

4. Click on the Docker button to build the image and run it inside a Docker container, rather than in IIS Express.

5. You could verify that your container is running using the Docker command-line tools; open a cmd or Terminal and type in docker container ls to view the containers.

That's it, you have successfully added Docker support to your ASP.NET core app and your app is now running inside a Docker container.

An exception is a runtime error in a program that violates a system or application constraint, or a condition that is not expected to occur during the normal execution of the program.

A well-designed app must handle exceptions and prevent the app from crashing. This article describes some of the best practices to follow while handling exceptions in C#.

1. Use throw instead of throw ex.
2. Log the exception object while logging exceptions.
3. Avoid catch block that just rethrows it.
4. Do not swallow the exception.
5. Throw exceptions instead of returning an error code.
6. Common failure conditions should be handled without throwing exceptions.
7. Use grammatically correct and meaningful error messages.
8. ApplicationException should never be thrown from code.
9. Use the predefined exception types.
10. End custom exception class names with the word Exception.

1. Use throw instead of throw ex

Using throw ex inside a catch block does not preserve the stack trace and the original offender would be lost. Instead use throw as it preserves the stack track and the original offender would be available.

// Bad code
catch(Exception ex)
{
    throw ex; // Stack trace will show this line as the original offender.
}

// Good code
catch(Exception ex)
{
    throw; // The original offender would be rightly pointed.
}

Read more about this on my blog - Exception handling in C# - throw or throw ex

2. Log the exception object while logging exceptions

Often developers log just the exception message to the logging system without the exception object. The exception object contains crucial information such as exception type, stack trace, etc. and it's very important to log it.

If you are using the ILogger, there are extension methods to LogError, LogCritical, Log, etc that accepts exception object as a parameter; use those instead of just the message ones.
LogCritical(Exception exception, string message, params object[] args)
LogError(Exception exception, string message, params object[] args)
Log(LogLevel logLevel, Exception exception, string message, params object[] args)

// Bad code
catch (DivideByZeroException ex)
{
    // The exception object ex is not logged, thus crucial info is lost
    this.logger.LogError("Divide By Zero Exception occurred");
}

In the above example, the exception object ex is not logged resulting in loss of stack trace.

// Good code
catch (DivideByZeroException ex)
{
    this.logger.LogError(ex, "Divide By Zero Exception occurred");
}

3. Avoid catch block that just rethrows it

Don't simply catch an exception and just re-throw it. If the catch block has no other purpose, remove the try-catch block and let the calling function catch the exception and do something with it.

// Bad code
public void Method1() {
    try {
        Method2();
    }
    catch (Exception ex) {
        // Code to handle the exception
        // Log the exception
        this.logger.LogError(ex);
        throw;
    }
}

public void Method2() {
    try {
        // Code that will throw exception
    }
    catch (Exception) {
        throw;
    }
}

In the above example, Method1 is calling Method2 and there is a possibility of an exception occurring in Method2. The catch block in Method2 does nothing with the exception and just re-throws it.
Instead, the try-catch block in Method2 can be removed and the caller which is Method1 in this case can catch the exception and handle it.

// Good code
public void Method1()
{
    try
    {
        Method2();
    }
    catch (Exception ex) {
        // Code to handle the exception
        // Log the exception
        this.logger.LogError(ex);
        throw;
    }
}

public void Method2()
{
    // Code that will throw exception

    // No try-catch block here  
    // as this method doesn't know how to handle the exception
}

4. Do not swallow the exception

One of the worst things to do in exception handling is swallowing the exception without doing anything. If the exception is swallowed without even logging there won't be any trace of the issue that occurred. If you are not sure of what to do with the exception, don't catch it or at least re-throw it.

// Bad code
try
{
    // Code that will throw exception
}
catch (Exception ex)
{
}

5. Throw exceptions instead of returning an error code

Sometimes instead of throwing exceptions developers return error codes to the calling function, this might lead to exceptions going unnoticed as the calling functions might not always check for the return code.

// Bad code
public int Method2()
{
    try 
    {
        // Code that might throw exception
    }
    catch (Exception) 
    {
        LogError(ex);
        // This is bad approach as the caller function 
        // might miss to check the error code.
        return -1;
    }
}

6. Common failure conditions should be handled without throwing exceptions

For conditions that are likely to occur and trigger an exception, consider handling them in a way that will avoid the exception. Example -

• Close the connection only after checking if it's not already closed.
• Before opening a file, check if it exists using the File.Exists(path) method.
• Use fail-safe methods like - CreateTableIfNotExists while dealing with databases and tables.
• Before dividing, ensure the divisor is not 0.
• Check null before assigning value inside a null object.
• While dealing with parsing, consider using the TryParse methods.

// Bad code
int.Parse(input);

// Good code
int.TryParse(input, out int output);

7. Use grammatically correct and meaningful error messages

Ensure that the error messages are clear and end with a period. The exception message should not be abrupt and open-ended. Clear and meaningful messages give the developer a good idea of what the issue could have been while trying to replicate and fix the issue.

// Bad code
catch (FileNotFoundException ex)
{
    this.logger.LogError(ex, "Something went wrong");
}

// Good code
catch (FileNotFoundException ex)
{
    this.logger.LogError(ex, "Could not find the requested file.");
}

8. ApplicationException should never be thrown from code

In the initial design of .NET, it was planned that the framework will throw SystemException while user applications will throw ApplicationException. However, a lot of exception classes didn't follow this pattern and the ApplicationException class lost all the meaning, and in practice, this found to add no significant value.

Hence it's advised that you should not throw an ApplicationException from your code and you should not catch an ApplicationException too unless you intend to re-throw the original exception. Also custom exceptions should not be derived from ApplicationException.

9. Use the predefined exception types

There are many exceptions already predefined in .NET. Some of them being:

• DivideByZeroException is thrown if the divisor is 0.
• ArgumentException, ArgumentNullException, or ArgumentOutOfRangeException is thrown if invalid parameters are passed.
• InvalidOperationException is thrown if a method call or property set is not appropriate in the object's current state.
• FileNotFoundException is thrown if the file is not present.
• IndexOutOfRangeException is thrown if the item being accessed from an array/collection is outside its bounds.

The predefined exceptions are sufficient in most of the cases. Hence introduce a new custom exception class only when a predefined one doesn't apply or you would like to have some additional business analytics based on some custom exception, e.g. A custom exception - TransferFundsException can be used to keep track of fund transfer exceptions and generate business analytics & insights from it.

10. End custom exception class names with the word Exception

As mentioned earlier, the predefined exception types are sufficient in most of the cases, but when a custom exception is necessary, name it appropriately and end the exception name with the word "Exception".

Also, ensure that the custom exception derives from the Exception class and includes at least the three common constructors :

• Parameterless constructor
• Constructor that takes a string message
• Constructor that takes a string message and an inner exception

Example:

using System;

public class TransferFundsException : Exception
{
    public TransferFundsException()
    {
    }

    public TransferFundsException(string message)
        : base(message)
    {
    }

    public TransferFundsException(string message, Exception inner)
        : base(message, inner)
    {
    }
}

Final Thoughts

These are some of the exception handling practices that I use and find very helpful in my day-to-day work. Some of the above ones might look obvious, but often go unnoticed by many. Let me know your thoughts and do mention any other exception handling practices that you follow.

The most common, naive and frequent code that we see to achieve this is :

var userId = 1;
var completed = true;
var someParamValue = "abc";

Uri baseAddress = new Uri("https://jsonplaceholder.typicode.com/");
Uri apiUrl = new Uri($"/todos?userId={userId}&completed={completed}" +
                $"&someParam={someParamValue}", UriKind.Relative);

And the typical issue with the above code is that you could accidentally miss the starting ? or the & and = in the query parameters and create bugs; another issue is the readability of the code. When there is a high number of query parameters in the url, the code tends to be messy and unclean.

Flurl to the rescue.

Flurl is a modern, fluent, asynchronous, testable, portable, buzzword-laden URL builder and HTTP client library for .NET

Flurl adds extension methods to strings which helps us easily add path segment, set query params, set fragment, etc. in a clean and elegant manner.

Installing Flurl

Flurl can be installed via NuGet Package manager console as:
PM> Install-Package Flurl

Or via the NuGet Package manager UI:

Once installed, import the Flurl namespace and convert the messy URLs to more readable ones.

The initial code can now be modified and constructed with flurl as :

using Flurl;

string url = "https://jsonplaceholder.typicode.com/"
    .AppendPathSegment("todos")
    .SetQueryParam("userId", userId)
    .SetQueryParam("completed", completed)
    .SetQueryParam("someParam", someParamValue);

Apart from SetQueryParam there's also SetQueryParams extension that accepts object, any collection of key-value pairs, Tuples, or a Dictionary object.

Flurl extension methods are available on String as well on System.Uri. In either case, it's easy to convert back and forth using the ToString() and ToUri() methods.

using Flurl;

Uri url = "https://jsonplaceholder.typicode.com/"
    .AppendPathSegment("todos")
    .SetQueryParams(new
    {
        userId = userId,
        completed = completed,
        someParam = someParamValue
    })
    .ToUri();

Flurl provides lots of other utilities and extension methods too. Do check out flurl documentation for more details.

An exception is a runtime error in a program that violates a system or application constraint, or a condition that is not expected to occur during the normal execution of the program.

Exceptions occur due to bad user input or bad code, unexpected conditions at runtime, unavailable resources, and so on. For example, attempting to read a file that doesn't exist, trying to divide a number by zero, attempting to insert data to a table that doesn't exist, etc. will all throw exceptions. When exceptions are not handled properly, it leads to the crashing of the application!

Handling Exceptions

Handling exceptions ensures that our application does not crash, also it gives us a chance to exit gracefully with some meaningful message or in some scenarios a second chance to fix the issue.

C# provides built-in support to handle the exception using try, catch & finally blocks.

try
{
    // Code to try goes here.
}
catch (SomeSpecificException ex)
{
    // Code to handle the exception goes here.
}
finally
{
    // Code to execute after the try (and possibly catch) block goes here.
}

After an exception is thrown, the runtime checks the current statement to see whether it is within a try block. If it is, any catch blocks associated with the try block are checked to see whether they can catch the exception. Catch blocks typically specify exception types; if the type of the catch block is the same type as the exception or a base class of the exception, the catch block can handle the method.

If the statement that throws an exception isn't within a try block or if the try block that encloses it has no matching catch block, the runtime checks the calling method for a try statement and catch blocks. The runtime continues up the calling stack, searching for a compatible catch block. After the catch block is found and executed, control is passed to the next statement after that catch block.

One of the crucial best practices in exception handling is to ensure that the exception is not swallowed, rather it should bubble up to the caller or the topmost part of your application so that the entire stack trace is maintained.

Difference between throw and throw ex

So what's the fuss here? Exception handling seems simple right?
Well, many times developers often use throw; or throw ex; interchangeably inside the catch block, and that's where the main difference occurs.

To better understand the difference let's take an example of a simple Calculator Application that implements just division for now.

using System;

namespace CalculatorApp
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Enter the dividend");
            int.TryParse(Console.ReadLine(), out int dividend);

            Console.WriteLine("Enter the divisor");
            int.TryParse(Console.ReadLine(), out int divisor);

            Console.WriteLine(Divide(dividend, divisor));
        }

        static int Divide(int dividend, int divisor)
        {
            try
            {
                return dividend / divisor;
            }
            catch (DivideByZeroException ex)
            {
                Console.WriteLine("Cannot divide by 0");
                throw; //Re-throw the error
            }
        }
    }
}

Here, we have the Divide method which does the division of inputted numbers and is called from the Main function. When a number is divided by 0, it throws the DivideByZeroException and in our code, we catch this exception and log it to the console.

Now let's look at the stack trace being printed with just throw; statement from the catch block when a divide by zero exception occurs:

catch (DivideByZeroException ex)
{
    Console.WriteLine("Cannot divide by 0");
    throw; //Re-throw the error
}

Unhandled exception. System.DivideByZeroException: Attempted to divide by zero.
   at CalculatorApp.Program.Divide(Int32 dividend, Int32 divisor) in C:\Blog\CalculatorApp\Program.cs:line 22
   at CalculatorApp.Program.Main(String[] args) in C:\Blog\CalculatorApp\Program.cs:line 15

From the stack trace we see the exact method and line number where the exception occurred, in this case, line number 22 of the Divide function in Program class.
throw; propagated the error while preserving the information on where exactly it occurred.

Now let's change the catch block to throw the caught exception object - throw ex and analyze the stack trace being printed.

catch (DivideByZeroException ex)
{
    Console.WriteLine("Cannot divide by 0");
    throw ex; //throwing the caught exception object
}

Unhandled exception. System.DivideByZeroException: Attempted to divide by zero.
   at CalculatorApp.Program.Divide(Int32 dividend, Int32 divisor) in C:\Blog\CalculatorApp\Program.cs:line 27
   at CalculatorApp.Program.Main(String[] args) in C:\Blog\CalculatorApp\Program.cs:line 15

You can see that the stack trace points to line number 27 as the cause of the exception, but in fact, it's the line where the exception was thrown and not where it occurred. We missed the crucial information of where the exception exactly occurred.

throw or throw ex : The Conclusion

Handling exceptions is a crucial part of software development. It's necessary to understand the basics and the implication of using different throw statements. Developers often spend hours debugging an issue just because they don't have the right stack trace to point the line where the exception exactly occurred due to the way exception was thrown.

In simple terms:
throw preserves the stack trace (the original offender would be available)
throw ex does not preserve the stack trace (the original offender would be lost)

The stack trace loss is very evident when the exceptions bubble up the call stack. Use of throw ex will lead to loss of crucial stack trace.

To conclude, always ensure that you re-throw an exception - that is simply calling throw without an exception object.

Thanks to Tina Holly's blog post and scripts which helped me migrate my WordPress blog site to Hashnode. This blog post builds on the same but provides a more detailed guide on the migration.

We will cover the migration in 4 main steps :

• Download post content from WordPress
• Download images
• Publish posts to Hashnode using their API
  • Get migration scripts
  • Clean the downloaded posts
  • Publish posts to Hashnode
• Backdate the posts and manually fix the images

Download post content from WordPress

To begin the migration, you would need to first download your existing posts on WordPress. By default, these are in XML format, but we will use the WP Import Export Lite to export the posts as JSON.

1. Head to your WordPress site's admin panel.
2. Navigate to Plugins -> Add New and search for wp import export lite.
3. Install and Activate the 'WP Import Export Lite' plugin.
4. Now that the plugin is installed and activated, click on the Export option in the plugin.
5. On the New Export options page,
   1. Choose export type as Post.
   2. Leave the filtering options & fields section as is.
   3. In the advanced options section, choose export file type as JSON.
   4. Click on the Customize Export File button at the top right corner to begin the export.
   5. Once the export process is completed, click on the Download button to download the post's json file.
   6. The downloaded file will have an array of objects having the following shape.

      {
       "ID": "161",
       "Title": "Understanding CRON Expressions",
       "Content": "Many Azure resources like web jobs, Azure functions, logic apps use CRON expression [...]",
       "Excerpt": "",
       "Date": "August 29, 2018",
       "Post Type": "post",
       "Permalink": "http:\/\/kumarashwinhubert.com\/2018\/08\/29\/understanding-cron-expressions\/"
      }
      

   7. Rename the downloaded json file to posts.json

Download images

Next, you will need to download all your images from WordPress. Images are stored in the ./wp-content/uploads directory by year and month. There are many ways to download the images, but the easiest one is to use an SFTP tool to download this folder.

wp-content/
 uploads
     2018
        01
        02
        03
     2019
         01
         02
         03

Note: Currently there's no automatic way to migrate the images along with your blog post content. This article targets manually uploading the image to hashnode's CDN and updating the migrated blog posts at the end. In case you wish to use some other storage provider, please upload the images and replace the url in the posts.json file before proceeding further.

Publish posts to Hashnode using their API

Hashnode has a GraphQL API. It's somewhat limited in functionality but has most of the basic features. The API we intend to use is the createPublicationStory; but instead of manually cleaning the downloaded posts json and creating the request body to hit the API, we can use the migration scripts present in WordPress-Hashnode Migrator GitHub project.

The next set of steps will use this GitHub project to clean and publish the posts. This project is a node application hence ensure node is installed on your system.

Get migration scripts

1. Clone the WordPress-Hashnode Migrator project from GitHub.
2. Copy the downloaded posts.json from the earlier step to the root of the cloned project.
3. Rename the .env.sample to .env The folder structure will look like this:
4. Open a terminal in the cloned project and install the dependencies:

   npm install
   

Clean the downloaded posts

This step processes the posts in ./posts.json and performs the following actions:

• removes dirty attributes from content HTML
• converts post content to Markdown
• writes a new file in ./posts/cleaned.json

Run the following command to clean the posts.

npm run cleanse

Publish posts to Hashnode

Ensure that you have already created a Hashnode site; if not, now would be a good time to create one as we need the Publication_Id and API_Key to continue.

1. Head to the dashboard of your hashnode site. Copy and keep the publicationId from the url which would be in the form https://hashnode.com/[Publication_Id]/dashboard
2. Navigate to the Developer settings page - https://hashnode.com/settings/developer and Generate New Token.
3. Open the .env file in the project. Replace the HASHNODE_PUBLICATION_ID value with your publication id and HASHNODE_API_KEY with your generated key.

The .env file should look like this :

HASHNODE_PUBLICATION_ID=602xxxa999eabxxxxxxx1a9b
HASHNODE_API_KEY=030xx44x-exx6-4xx4-8xxe-52xxxxxxxx1a

Save the .env file and head back to the terminal and run the following command to publish the posts to hashnode.

npm run migrate

Once the script executes successfully, the blog posts would have been published to your hashnode site.

Backdate the posts and manually fix the images

Currently backdating the posts is not supported in Hashnode's GraphQL API, hence it's required to manually update the backdate on each of the posts.

Navigate to each of the migrated posts and click on Edit -> Settings and set the backdate. Also set the tags & Cover Image if required.

As mentioned earlier, there isn't an easy way to migrate the images from your WordPress blog. You need to manually update the image in each blog post.

Navigate to each of the migrated posts and you would see the references to old images in the form of /wp-content/uploads/2020/08/filename.png. Use the Upload an image option in hashnode editor to upload the image from the WordPress images downloaded earlier.

Conclusion

That's it !!!
Your hashnode blog is up and running with all your migrated WordPress posts.

Hope this helped you in your migration journey from WordPress to Hashnode.

There are many workarounds for making the async calls from Main method, but I like to keep the Main method async and do an await inside it just like any other method. And this is now possible with C# version greater than 7.1

To do so, Right click on your project and select Properties and navigate to the Build Tab. There, click on Advanced button at the bottom.

In the Advanced menu, for the Language Version chose any c# version greater than 7.1

In case you can't see C# 7.1 or greater, please install any pending updates to your Visual Studio. And now you can change the Main method to :

 static async Task Main(string[] args)

and do the await inside it.

Understanding the expression

As mentioned earlier, a CRON expression includes six fields:

{second} {minute} {hour} {day} {month} {day-of-week}

And each field can have one of the following values:

CRON Examples

Some of the frequently used CRON expression samples

Common pitfalls:

The CRON expression 0 0 */5 * * * means every 5 hours. So it executes at 00:00:00, 05:00:00, 10:00:00, 15:00:00, 20:00:00, 00:00:00 ... So it's not exactly every 5 hours. If you want a regular frequency, the following expressions are good:

• For minutes and seconds : /2, /3, /4, /5, /6, /10, /12, /15, /20 and /30 (60 is divisible by these numbers)
• For hours : /2, /3, /4, /6, /8 and /12
• For Months : /2, /3, /4 and /6
• For days : Nothing actually because there are leap years and months with 28, 29, 30 or 31 days.

If you want a cyclic approach, all other values can lead to "wrong" executions at the end of the cycle. e.g. Every 10 hours executes at 00:00:00, 10:00:00, 20:00:00, 00:00:00 (only 4 hours, not 10).

You can find CRON expression examples online, but many of them omit the {second} field. In case you copy one of them, remember to add the missing {second} field. Also, you will want a zero in that field and not an asterisk

Additional references:

Time trigger for Azure Functions: https://docs.microsoft.com/en-us/azure/azure-functions/functions-bindings-timer

CRON Expression Descriptor: https://cronexpressiondescriptor.azurewebsites.net/

So what we need is to add more intelligence to the fields inside the FormFlow and LUIS is the perfect cognitive service which does this. As it is we use LUIS in a BOT (most of the time), now we need to make the FormFlow fields also be processed through LUIS.

The approach we are gonna take is call the LUIS API in the validate method of the form flow field.

1. Add a LuisModelEndpoint key to your web.config file. The value would be the LUIS endpoint URL exposed by your Luis app. You can find the endpoint by going to the Publish tab of your Luis app.

   Your web.config will look something like this :

   <appSettings>
     <!-- update these with your BotId, Microsoft App Id and your Microsoft App Password-->
     <add key="BotId" value="YourBotId" />
     <add key="MicrosoftAppId" value="" />
     <add key="MicrosoftAppPassword" value="" />
     <add key="LuisModelEndpoint" value="https://westus.api.cognitive.microsoft.com/luis/v2.0/apps/YOUR_MODEL_ID?subscription-key=YOUR_SUBSCRIPTION_KEY&verbose=true&timezoneOffset=0&q="/>
   </appSettings>
   

2. Now let's add the Luis response class so that we can deserialize the API response. Create a class called LUISOutput and paste in the below code.

   public class LUISOutput
   {
       public string query { get; set; }
       public LUISIntent[] intents { get; set; }
       public LUISEntity[] entities { get; set; }
   }
   public class LUISEntity
   {
       public string Entity { get; set; }
       public string Type { get; set; }
       public string StartIndex { get; set; }
       public string EndIndex { get; set; }
       public float Score { get; set; }
   }
   public class LUISIntent
   {
       public string Intent { get; set; }
       public float Score { get; set; }
   }
   

3. Inside your FormFlow class, add a method named GetIntentAndEntitiesFromLUIS which will query Luis for the user input and find in the entities and the intents. The code would be:

   public static async Task<LUISOutput> GetIntentAndEntitiesFromLUIS(string Query)
       {
           Query = Uri.EscapeDataString(Query);
           LUISOutput luisData = new LUISOutput();
           try
           {
               using (HttpClient client = new HttpClient())
               {
                   string RequestURI = WebConfigurationManager.AppSettings["LuisModelEndpoint"] + Query;
                   HttpResponseMessage msg = await client.GetAsync(RequestURI);
                   if (msg.IsSuccessStatusCode)
                   {
                       var JsonDataResponse = await msg.Content.ReadAsStringAsync();
                       luisData = JsonConvert.DeserializeObject<LUISOutput> (JsonDataResponse);
                   }
               }
           }
           catch (Exception ex)
           {
   
           }
           return luisData;
       }
   

4. The base structure is ready. Now you could call this method in the validate function of your individual form flow fields. For example, lets take a Patient registration form flow which asks for 'Name', 'Gender', 'Phone Number', 'DOB'. If I want to apply luis to the Name field, the code would be :

   return new FormBuilder<RegisterPatientForm>()
           .Field(nameof(person_name),
           validate: async (state, response) =>
           {
               var result = new ValidateResult { IsValid = true, Value = response };
   
               //Query LUIS and get the response
               LUISOutput LuisOutput = await GetIntentAndEntitiesFromLUIS((string)response);
   
               //Now you have the intents and entities in LuisOutput object
               //See if your entity is present in the intent and then retrieve the value
               if (LuisOutput != null && Array.Find(LuisOutput.intents, intent => intent.Intent == "GetName") != null)
               {
                   LUISEntity LuisEntity = Array.Find(LuisOutput.entities, element => element.Type == "name");
   
                   if (LuisEntity != null)
                   {
                       //Store the found response in resut
                       result.Value = CultureInfo.CurrentCulture.TextInfo.ToTitleCase(LuisEntity.Entity);
                   }
                   else
                   {
                       //Name not found in the response
                       result.IsValid = false;
                   }
               }
               else if (LuisOutput != null && Array.Find(LuisOutput.intents, intent => intent.Intent == "None") != null)
               {
                   //In case of none intent assume that the user entered a name
                   result.Value = LuisOutput.query;
               }
               else
               {
                   result.IsValid = false;
               }
               return result;
           })
   

   That's all, now on user input, the formflow will call luis and based on the response, the values would be set into the form fields.

You can find the complete project solution in my GitHub repo.

Open & Close Sidebar - Ctrl + b

You can easily open and close the sidebar with Ctrl + b . This really comes in handy when you are on a small screen and would like to save the display area.

Quick open - Ctrl + p

When you want to open the recent files or open a specific file, you can use Ctrl + p to get a search bar and open the file from there.

Keep Open - Ctrl + k Enter

When you open the file by a single click from the sidebar or through the quick open, the file will be replaced by the next file you open. So in case you want to keep open the current file, type in Ctrl + k Enter You can also notice the changes in the file name in the top bar once you "keep open" the file.

Integrated Terminal - Ctrl + `

To quickly open/close the integrated terminal use Ctrl + ` . Integrated Terminal is a really handy tool when you want to execute commands without opening a separate terminal or command prompt.

Code Formatting - Alt + Shift + f

To format the entire document you can use Alt + Shift + f . This is really useful when you want to follow same formatting rules across files.

Search within folder - Ctrl + Shift + f

While Ctrl + f allows you to search within the current file, Ctrl + Shift + f allows you to search within your open folder.

Select Word - Ctrl + d

To select the entire word where your cursor is on, use Ctrl + d , If you hit Ctrl + d more than once, youll add another occurrence of the same keyword to your selection. This is very useful when you want to change the multiple occurrences of the same word.

Select all occurrences of selection - Ctrl + Shift + L

In case you want to change a particular word or get the cursor across all the occurrences of word or selection use Ctrl + Shift + L. Alternatively, you can also use Ctrl+F2 to get the same behavior.

Close the currently open file - Ctrl + w

Close the open file with this shortcut instead of hovering over the tab finding the 'x' and clicking it. To close all the open files, use Ctrl + k w.

Command Palette - Ctrl + Shift + p

One of the most important feature of VS Code is Command Palette. It lets you execute tasks in VS code. Use Ctrl + Shift + p to bring up the command palette. You can type in any task you want to achieve and VS Code will search for the task for you. If a keyboard shortcut exists, it will show that too.

That's it! The top 10 keyboard shortcuts for VS code. To view all the available shortcuts use Ctrl + k Ctrl + s or Ctrl + k s To read more about all the key bindings, visit the official keybindings document .

The evolution of your APIs functionality is inevitable, but the headache of maintaining API docs doesnt have to be. Swagger tools takes the hard work out of generating and maintaining your API docs, ensuring your documentation stays up-to-date as your API evolves.

swagger.io

Installing Swagger

To add swagger to your web API project, you need to install the Swashbuckle NuGet to the project.

Right click on your API project and choose "Manage NuGet Packages". In the Package manager window, search for "Swagger" or "Swashbuckle" and install it.

And that's it, swagger would be enabled on your project. Run the project and navigate to "http://YOUR_PROJECT_URL/swagger" for e.g. "http://localhost:1357/swagger" and you would see the swagger API documentation for your project.

What happened in the back

Well, though just installing a NuGet got the job done, it's good if you know how things are wired up and what changes are recommended to do.

If you look inside your App_Start folder, you would notice a new auto-generated file called SwaggerConfig.cs and this is where the configuration for Swagger exists.

At the minimum, you will need the following configuration to enable swagger. (This is the one that's already there inside the SwaggerConfig.cs)

GlobalConfiguration.Configuration
    .EnableSwagger(c =>
    {
        c.SingleApiVersion("v1", "API Title");
    })
    .EnableSwaggerUi(c =>{});

And if you notice the line above the namespace, you would find this line of code that does the wiring up ( registering it )

[assembly: PreApplicationStartMethod(typeof(SwaggerConfig), "Register")]

We generally don't want Config registrations lying around here and there and always prefer to keep it in a single place - the Global.asax file. Go ahead and comment/delete that line from your SwaggerConfig and add SwaggerConfig.Register(); to your Global.asax file. So your Global.asax file should look something like this at the bare minimum :

So now the registration happens from the Application_Start() method, and all our config registrations are in a single file.

Why use Swagger

The next important question, why swagger? What benefits does it provide?

The main thing is that each public action method in your controllers can be tested from the Swagger UI. Click a method name to expand the section, add the necessary parameters, if any and click Try it out!. You can see the responses as well as the expected model.

Similar one goes for a POST request as well. You can see the expected model for the request and test it out with a sample model from the Swager UI itself.

No need for POSTMAN or other tools for testing the API. Pretty cool right!! Don't forget to try out Swagger in your next project.

But there is a simple way to have Visual Studio show the active files in solution explorer. Goto Tools Options and Select Projects and Solutions and enable "Track Active Item in Solution Explorer "

And that's it. Navigate across files and the solution explorer will also navigate along with you.

As you can see in the above image, a deleted branch (feature1 branch) still shows up in visual studio.

So to remove, first let's check which branches have to be pruned (remove reference). Run

git remote prune origin --dry-run

The argument --dry-run just mimics the prune and does not actually remove it.

Now to remove the branches, run the prune command without the --dry-run argument.

git remote prune origin

If you go ahead and check in visual studio, you wouldn't find the pruned branches inside remote.

If you want to remove the local branch as well; right-click on that branch in visual studio and choose delete from the context menu.

Alternatively, you could also run

git branch -d feature1

in a terminal window.

That's it!! You have removed references to your unused local and remote branches!