Introduction

In recent years, Swagger has been a go-to solution for generating API documentation in the .NET ecosystem. However, with the release of .NET 9, Microsoft has decided to step away from Swagger as the default API documentation tool, opting for native OpenAPI support through the Microsoft.AspNetCore.OpenApi library. This shift has generated some discussions, particularly for developers who are accustomed to Swagger’s ease of use and interactive interface.

In this post, we’ll dive into what’s changed, why it matters, and how developers can adapt to this shift.

What’s Changing in .NET 9?

Swagger, once bundled by default, is now replaced by Microsoft.AspNetCore.OpenApi, a new library for generating OpenAPI specifications. The biggest change here is that the interactive Swagger UI is no longer included by default. Developers now have the option to use additional tools like Swashbuckle or NSwag to keep that feature.

Setting Up OpenAPI in .NET 9

Here’s how to quickly get started with OpenAPI in .NET 9:

1. Create a New Web API Project: If you don’t have a project, create one:

dotnet new webapi -n MyApi
cd MyApi

2. Add OpenAPI Support: The new Microsoft.AspNetCore.OpenApi library is required:

dotnet add package Microsoft.AspNetCore.OpenApi

3. Update Program.cs to Include OpenAPI:

builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();  // Optional, if you want to use Swagger manually
var app = builder.Build();

app.UseOpenApi(); // Generates OpenAPI spec
app.UseSwaggerUi3(); // Optional, if you need Swagger UI

Now, your API will have OpenAPI documentation generated and optionally display Swagger UI for testing endpoints.

Alternatives to Swagger in .NET 9

While Swagger is no longer bundled by default, you can still use tools like:

• Swashbuckle: Add it manually if you want the familiar Swagger UI.
• NSwag: An actively maintained alternative with support for Swagger UI and OpenAPI generation.

Why This Matters

By shifting to native OpenAPI support, Microsoft is streamlining API documentation within .NET 9, offering a more flexible and standardized approach. Although this removes the automatic inclusion of Swagger’s interactive UI, developers now have the ability to customize their documentation solutions.

Whether you choose to stick with Swashbuckle, explore NSwag, or fully embrace native OpenAPI, the move is a step toward better, more standardized API documentation in .NET.

Introduction

Azure Functions is a serverless compute service offered by Microsoft Azure, allowing developers to build and deploy applications without worrying about the underlying infrastructure. With Azure Functions, you can execute code in response to various triggers, and it supports several types of functions to cater to different use cases. In this blog post, we’ll explore some of the key types of Azure Functions.

1. HTTP Trigger Functions:

• HTTP trigger functions are invoked via HTTP requests. They are commonly used for building APIs and web applications.
• You can configure these functions to respond to various HTTP methods, such as GET, POST, PUT, DELETE, etc.
• Ideal for building RESTful APIs and handling HTTP-based events.

2. Timer Trigger Functions:

• Timer trigger functions are executed on a predefined schedule or time interval.
• These functions are useful for implementing scheduled tasks, automated cleanup processes, and periodic data processing.

3. Queue Trigger Functions:

• Queue trigger functions are triggered by messages in Azure Storage Queues, Azure Service Bus Queues, or Azure Event Hubs.
• They are often used for asynchronous processing, decoupling components of a system, and handling events or messages.

4. Blob Trigger Functions:

• Blob trigger functions respond to the creation or modification of blobs (binary large objects) in Azure Blob Storage.
• They are excellent for scenarios involving file processing, image resizing, or data transformation when new blobs are added.

5. Event Grid Trigger Functions:

• Event Grid trigger functions are invoked when events are published to Azure Event Grid topics or custom events.
• They are suitable for building event-driven architectures and reacting to various events within Azure services.

6. Service Bus Trigger Functions:

• Service Bus trigger functions process messages from Azure Service Bus topics or subscriptions.
• They enable the development of reliable and scalable messaging solutions.

7. Cosmos DB Trigger Functions:

• Cosmos DB trigger functions are triggered by changes in Azure Cosmos DB collections.
• They help build real-time data processing applications and keep data in sync with downstream systems.

8. IoT Hub Trigger Functions:

• IoT Hub trigger functions process telemetry data sent from IoT devices through Azure IoT Hub.
• These functions are vital for building IoT solutions and performing real-time data analytics.

9. Durable Functions:

• Durable Functions is an extension of Azure Functions that allows you to build stateful and serverless workflows.
• They provide capabilities for orchestrating complex workflows, fan-out/fan-in patterns, and managing long-running processes.

10. Custom Trigger Functions:

• Azure Functions can also be extended to create custom triggers tailored to your specific requirements.
• This flexibility allows you to handle custom events or integrate with external systems seamlessly.

Conclusion

By offering these various types of functions, Azure Functions empowers developers to build a wide range of serverless applications and microservices. Choosing the right function type for your project depends on the specific use case and the trigger mechanism that best fits your application’s needs. Whether you’re building a web API, processing data, or responding to events, Azure Functions has you covered with its versatile set of function types.

When you create an Event Grid webhook subscription, Event Grid sends a validation request to the endpoint you specified. This request contains a validation code that you must return to Event Grid to confirm that you control the endpoint.

Here’s an example of how to perform a webhook validation handshake with code:

1. Create a webhook subscription with a validation URL endpoint. You can use the Azure CLI or Azure Portal to do this.
2. When Event Grid sends a validation request to the endpoint, you’ll receive a POST request with a validation code in the request body. The request will look like this:

3. To validate your subscription, your endpoint must respond with the same validation code that was sent in the request body. Here’s an example of how to respond:

4. Event Grid will check if the validation code matches the code it sent, and if it does, the subscription will be validated and events will start flowing to your endpoint.

5. Note that you must respond with a 200 OK HTTP status code and an empty response body to confirm the subscription. If you don’t, Event Grid will continue to send validation requests until the subscription is confirmed.

Here’s an example of how to create a .NET POST method to handle the Event Grid webhook validation handshake with code:

[HttpPost]
public IActionResult HandleEventGridSubscriptionValidation([FromBody]JObject eventData)
{
    // Get the validation code and validation URL from the request body
    string validationCode = eventData["validationCode"].ToString();
    string validationUrl = eventData["validationUrl"].ToString();

    // If the validation code exists, this is a validation request
    if (!string.IsNullOrEmpty(validationCode))
    {
        // Respond with the validation code to confirm the subscription
        return Ok(new
        {
            validationResponse = validationCode
        });
    }

    // If this is not a validation request, handle the event as desired
    // ...

    return Ok();
}

Code Explanation:

In this example, the HandleEventGridSubscriptionValidation method takes in a JSON object from the request body using the FromBody attribute. It then extracts the validation code and validation URL from the JSON object.

If the validation code exists, the method responds with the validation code to confirm the subscription by returning an HTTP 200 OK status code and an anonymous object with a validationResponse property set to the validation code.

If this is not a validation request, the method can handle the event as desired and return an HTTP 200 OK status code.

Note that this example uses the Newtonsoft.Json.Linq.JObject class to deserialize the JSON object in the request body. You may need to add a reference to the Newtonsoft.Json NuGet package and include the using Newtonsoft.Json.Linq; directive at the top of your code file to use this class.

Conclusion:

In conclusion, the Event Grid webhook validation handshake with code is an important security feature that verifies the endpoint for your Event Grid subscription. By confirming the subscription with the validation code, you can ensure that events are only sent to valid endpoints. In.NET, you can create a POST method to handle the validation request and respond with the validation code to confirm the subscription.

References:

Receive events from Azure Event Grid to an HTTP endpoint — Azure Event Grid | Microsoft Learn

WebHook event delivery — Azure Event Grid | Microsoft Learn

Introduction

As software projects grow in complexity, managing namespaces can become a time-consuming task. Global usings in C# 10 are a new feature that allow developers to specify namespaces that will be implicitly included in all files within a project, without having to explicitly add a using directive to each file. In this blog post, we’ll take a closer look at global usings in C# and how they can help improve code clarity.

Explanation of how global usings work in C# 10

To use global usings, you need to define them in a file called “globalUsings.cs”, which should be located in the project’s root directory. This file is automatically included in all compilation units in the project, which means that the namespaces specified in the file are available to all the project’s files.

Here’s an example of how global usings can be defined:

global using System;
global using System.Collections.Generic;
global using System.Linq;

In this example, we’ve defined three global usings for commonly used namespaces in C#. Now, in any file within the project, we can use classes and functions from these namespaces without needing to include a using directive for each one.

For example, if we wanted to use the List class from the System.Collections.Generic namespace, we could simply write:

var myList = new List<int>();

The List class is available in the file because we defined the System.Collections.Generic namespace as a global using.

It’s important to note that global usings can also be combined with traditional using directives. If you need to use a namespace that is not included as a global using, you can still include a using directive for it in a specific file.

using System.IO;

// ...

var fileStream = new FileStream("file.txt", FileMode.Open);

In this example, we’re using the FileStream class from the System.IO namespace, which is not included as a global using. Therefore, we need to include a traditional using directive in the file.

Conclusion

In conclusion, global usings are a powerful new feature in C# 10 that can help to reduce code clutter and improve code readability. By including commonly used namespaces globally, developers can spend more time focusing on the core logic of their programs, and less time managing using directives.

Introduction

Azure App Configuration is a service that allows developers to store and manage configuration settings for their applications in a centralized location. This can be useful for applications that need to have different settings based on the environment they are running in or for applications that have multiple instances and need to share configuration settings.

We will look at how to use Azure App Configuration in a.NET Core application in this blog post. We will cover the following topics:

1. Setting up an Azure App Configuration instance
2. Creating and managing configuration settings
3. Retrieving configuration settings in a .NET Core application

Setting up an Azure App Configuration instance

To get started, we need to create an Azure App Configuration instance in the Azure portal. To do this, follow these steps:

1. Navigate to the Azure portal (https://portal.azure.com).
2. Click on “Create a resource” in the left-hand menu.
3. Search for “App Configuration” and select it.
4. Fill in the required information, such as the subscription, resource group, and instance name.
5. Once the instance is created, navigate to it and copy the connection string. We will need this later in our code.

Creating and managing configuration settings

Once we have our Azure App Configuration instance set up, we can start creating and managing configuration settings. To do this, we can use the Azure portal or the Azure CLI.

To create a new configuration setting in the Azure portal, follow these steps:

1. Navigate to your Azure App Configuration instance.
2. Click on “Configuration settings” in the left-hand menu.
3. Click on “Add”
4. Enter the key and value for your configuration setting.

Retrieving configuration settings in a .NET Core application

Now that we have our Azure App Configuration instance set up and our configuration settings created, we can retrieve them in ours .NET Core application. To do this, we will need to install the Azure.Extensions.AspNetCore.Configuration.Secrets NuGet package. This package provides an implementation of the IConfiguration interface that retrieves configuration settings from an Azure App Configuration instance.

To install the package, open a command prompt or terminal window and run the following command:

dotnet add package Azure.Extensions.AspNetCore.Configuration.Secrets

Next, we need to configure our application to use the Azure App Configuration provider. To do this, we can modify the Program.cs file in our .NET Core application as follows:

using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.Hosting;

namespace MyApp
{
    public class Program
    {
        public static void Main(string[] args)
        {
            CreateHostBuilder(args).Build().Run();
        }

        public static IHostBuilder CreateHostBuilder(string[] args)
        {
            return Host.CreateDefaultBuilder(args)
                 .ConfigureWebHostDefaults(webBuilder =>
                 {
                     webBuilder.ConfigureAppConfiguration(config =>
                     {
                         //To retrieve the connection string for the Azure App Configuration service
                         var appUri = config.Build().GetConnectionString("appConfiguration");

                         //To add the Azure App Configuration service to the application configuration. 
                         config.AddAzureAppConfiguration(options =>
                         {
                             //Managed Identity:To authenticate the application with the Azure App Configuration service. 
                             var credential = new DefaultAzureCredential();

                             //To specify the URI for the Azure App Configuration service and the credential object for authentication
                             options.Connect(new Uri(appUri), credential);

                             //to configure the configuration settings are refresh. refresh behavior 
                             options.ConfigureRefresh(refresh =>
                             {
                                 //The Register method is called on the refresh object to register a named refresh event.The event is named refreshAll. 
                                 refresh
                                     //Sentinel Key
                                     .Register("refreshAll", true)
                                     //The SetCacheExpiration method is called on the refresh object to set the cache expiration time for the configuration settings.
                                     //Here, the cache expiration time is set to 5 seconds. 
                                     .SetCacheExpiration(TimeSpan.FromSeconds(5));
                             });
                         });

                     });
                     webBuilder.UseStartup<Startup>();
                 });
        }
    }
}

In ConfigureServices Method

//The AppConfiguration type is passed as a generic parameter to the Configure method,
//which specifies the type of the configuration object that will be bound to the AppConfiguration section of the application configuration.
services.Configure<AppConfiguration>(Configuration.GetSection("AppConfiguration"));

//This will allow the application to dynamically retrieve configuration settings from the Azure App Configuration service at runtime,
//without requiring any code changes or application restarts.
services.AddAzureAppConfiguration();

• This code block is configuring the Azure App Configuration service and binding a configuration section to a strongly typed AppConfiguration object in an ASP.NET Core application.
• The Configuration type is passed as a generic parameter to the Configure method, which specifies the type of the configuration object that will be bound to the AppConfiguration section of the application configuration.
• The AddAzureAppConfiguration method is then called on the services object to add the Azure App Configuration service to the application services.
• This will allow the application to dynamically retrieve configuration settings from the Azure App Configuration service at runtime, without requiring any code changes or application restarts.

In Configure Method

  //The Azure App Configuration middleware to the application pipeline,
  //the ASP.NET Core application can easily access and use configuration settings stored in the Azure App Configuration service,
  //making it easier to manage and update configuration settings across multiple environments and applications.
  app.UseAzureAppConfiguration();

• This code block is adding middleware to an ASP.NET Core application that enables it to use the Azure App Configuration service.
• The UseAzureAppConfiguration method is called on the app object to add the Azure App Configuration middleware to the application pipeline.

In Controller

 // IOptions is used for accessing configuration values that are read once and do not change
 //private readonly IOptions<AppConfiguration> _configuration;

 //IOptionsSnapshot is used for accessing configuration values
 //that can change during the application's lifetime.
 private readonly IOptionsSnapshot<AppConfiguration> _configuration;

 public AppConfigurationController(
    IOptionsSnapshot<AppConfiguration> configuration)
    {
      //"configuration" to retrieve the current configuration settings for the AppConfiguration type from the application configuration.
      _configuration = configuration;
    }

  [HttpGet]
  public string Get()
  {
    //This property represents a configuration setting that was stored in the Azure App Configuration service
    return _configuration.Value.Key1;
  }

In this code, we are configuring our application to use the Azure App Configuration provider by adding it to the IConfigurationBuilder. We are also passing in the connection string for our Azure App Configuration instance, which we retrieve from our appsettings.json file.

Introduction

The .NET ecosystem has seen remarkable growth in recent years, with new frameworks, libraries, and tools emerging to address a wide range of development needs. As the .NET ecosystem continues to grow, it becomes increasingly difficult for developers to find the right packages for their projects. That’s where NuGet.org comes in — a popular package repository that hosts over 200,000 packages. Recently, NuGet.org introduced a new feature that makes it easier to search for packages based on the target framework of your project.

Introducing Search By Target Framework

The new Search by Target Framework feature on NuGet.org allows developers to search for packages based on the target framework(s) of their project. This feature is particularly useful for developers who work on projects that target multiple frameworks. The feature helps them find packages that are compatible with all of their target frameworks, thereby ensuring smooth and hassle-free development experience.

Using Search By Target Framework

Using the Search by Target Framework feature on NuGet.org is straightforward. To use this feature, navigate to the search bar on NuGet.org and type in a search query. Once you have entered your search query, click on the “Filters” button to open the search filters. Under the “Target Framework” section, select the target framework(s) for your project. You can select multiple target frameworks if needed. Once you have selected the target framework(s), NuGet.org will display the packages that are compatible with the selected target framework(s) in the search results. This allows you to quickly find and download packages that are compatible with your project, without having to manually check each package’s compatibility.

Benefits of Search By Target Framework

The Search by Target Framework feature on NuGet.org offers several benefits to developers, including:

1. Saves Time: The Search by Target Framework feature saves developers time by eliminating the need to manually check package compatibility with each target framework. This can help developers to find and download compatible packages faster, ultimately improving the efficiency of their development process.
2. Ensures Compatibility: The feature ensures that developers are using packages that are compatible with all of their project’s target frameworks, thereby avoiding potential issues that could arise from using incompatible packages.
3. Improves Quality: Using the right packages for a project can improve the overall quality of the project, making it more stable, secure, and performant. The Search by Target Framework feature helps ensure that developers are using the right packages for their project, which ultimately contributes to the quality of the final product.

Conclusion

The Search by Target Framework feature on NuGet.org is a valuable addition to the .NET ecosystem. It offers developers a convenient and efficient way to find packages that are compatible with their project’s target frameworks, ultimately improving the quality and efficiency of their development process. If you are a .NET developer, consider taking advantage of this new feature to streamline your package search and selection process.

Note: Unfortunately its not Available on Visual Studio. They’re looking into it.

Introduction

Application Insights is a cloud-based application performance monitoring (APM) solution offered by Microsoft that allows you to monitor the health and performance of your .NET Core applications. By instrumenting your code, you can track things like request and response time, failures, and custom telemetry data that’s specific to your application. In this blog, we will go through the steps to connect your .NET Core application with Application Insights.

Step 1: Set up an Application Insights resource

The first step to get started with Application Insights is to set up an Application Insights resource in the Azure portal. If you don’t already have an Azure account, you can sign up for a free trial. Once you have an account, you can follow these steps to create a new Application Insights resource:

1. Go to the Azure portal
2. Click on the “Create a resource” button
3. Select “Application Insights” from the list of available resources
4. Fill in the required information for your resource (e.g., name, subscription, resource group, location)
5. Click the “Create” button to create your resource

Step 2: Install the Microsoft.ApplicationInsights.AspNetCore NuGet package

The next step is to install the Microsoft.ApplicationInsights.AspNetCore NuGet package in your .NET Core application. You can do this by using the NuGet Package Manager or by running the following command in the Package Manager Console:

Install-Package Microsoft.ApplicationInsights.AspNetCore

Step 3: Configure Application Insights in Startup.cs

The next step is to configure Application Insights in your Startup.cs file. You can do this by adding the following code to the ConfigureServices method:

builder.Services.AddApplicationInsightsTelemetry(Configuration["ApplicationInsights:InstrumentationKey"]);

Step 4: Add the Application Insights instrumentation key to appsettings.json

The final step is to add your Application Insights instrumentation key to your “appsettings.json” file. You can find this key in the Azure portal, under the “Overview” section of your Application Insights resource.

"ApplicationInsights": {
     "InstrumentationKey": "<YOUR INSTRUMENTATION KEY HERE>"
   }

Step 5: Log Data to Application Insights

Now that you have configured the SDK, you can start logging data to your Application Insights resource. There are several ways to do this, including using the ILogger interface provided by .NET Core, custom telemetry events, and custom metrics.

Using ILogger:

You can use the built-in ILogger interface in .NET Core to log data to Application Insights. To do this, you can inject an instance of ILogger into your classes and use its methods to log data. For example:

public class ApplicationInsights
{
 private readonly ILogger<ApplicationInsights> _logger;

 public ApplicationInsights(ILogger<ApplicationInsights> logger) => _logger = logger;

 public void ApplicationInsightsLogger()
 {
  _logger.LogInformation("ApplicationInsightsLogger Method was called.");
 }
}

Conclusion

In conclusion, logging data with Application Insights in a .NET Core application is a simple and powerful way to monitor, analyze, and troubleshoot your application. By following the steps outlined above, you can start logging data to your Application Insights resource and gain valuable insights into the performance and usage patterns of your application.