ASP.NET Core

The easiest and safest fix is to validate configuration values before Azure services are registered. This prevents accidental fallback authentication and gives clear feedback if something is missing.

Here’s a clean version of the solution:

public static IServiceCollection AddAzureResourceGraphClient(
    this IServiceCollection services,
    IConfiguration config)
{
    var connectionString = config["Authentication:AzureServiceAuthConnectionString"];

    if (string.IsNullOrWhiteSpace(connectionString))
        throw new InvalidOperationException(
            "Missing 'Authentication:AzureServiceAuthConnectionString' configuration."
        );

    services.AddSingleton(_ => new AzureServiceTokenProvider(connectionString));
    return services;
}

This small addition gives you:

✔ Clear error messages
✔ Consistent behavior between environments
✔ No more unexpected Azure calls during tests
✔ Easier debugging for teammates

For larger apps, you can also use strongly typed configuration + validation (IOptions<T>), which helps keep settings organized and ensures nothing slips through the cracks.

With this guard in place, your integration tests stay clean, predictable, and Azure-free unless you want them to involve Azure.

Most Azure SDK components rely on configuration values to know how to authenticate. For example:

new AzureServiceTokenProvider(
    config["Authentication:AzureServiceAuthConnectionString"]
);

If this key is missing, the Azure SDK does not stop. Instead, it thinks:
“I’ll figure this out myself!”

And then it tries fallback authentication options, such as:

• Developer login credentials
• Azure CLI authentication
• Managed Identity lookups
• Subscription scans

These attempts fail instantly inside a local test environment, leading to confusing “AccessDenied” messages.
The surprising part?
Your project may work fine during normal execution—but your API project or test project may simply be missing the same setting.

This tiny configuration mismatch means:

• Unit tests succeed
• API runs fine locally
• Integration tests fail dramatically

Once you understand this, the solution becomes much clearer.

Running integration tests in ASP.NET Core feels simple—until your tests start calling Azure without permission. This usually happens when you use WebApplicationFactory<T> to spin up a real application host. The test doesn’t run only your code; it runs your entire application startup pipeline.
That includes:

• Configuration loading
• Dependency injection setup
• Background services
• Azure clients and authentication providers

If your app registers Azure services during startup, they will also start up during your tests. And if the environment lacks proper credentials (which test environments usually do), Azure returns errors like:

• AccessDenied
• Forbidden

This can be confusing because unit tests work fine. But integration tests behave differently because they load real startup logic.
The issue isn’t Azure being difficult—it's your tests running more than you expect.

Understanding this is the first step to diagnosing configuration problems before Azure becomes part of your test run unintentionally.

Have you ever run an ASP.NET Core integration test and suddenly been greeted by an unexpected Azure “Access Denied” error? Even though your application runs perfectly fine everywhere else? This is a common but often confusing situation in multi-project .NET solutions. The short version: your tests might be accidentally triggering Azure authentication without you realizing it.

This Parent Snipp introduces the full problem and provides a quick overview of the three child Snipps that break down the issue step by step:

• Snipp 1 – The Issue:
  Integration tests using WebApplicationFactory<T> don’t just test your code—they spin up your entire application. That means all Azure clients and authentication logic also start running. If your test environment lacks proper credentials, Azure responds with errors that seem unrelated to your actual test.

• Snipp 2 – The Cause:
  The root cause is often a missing configuration value, such as an Azure authentication connection string. When this value is missing, Azure SDK components fall back to default authentication behavior. This fallback usually fails during tests, leading to confusing error messages that hide the real problem.

• Snipp 3 – The Resolution:
  The recommended fix is to add safe configuration validation during service registration. By checking that required settings exist before creating Azure clients, you prevent fallback authentication and surface clear, friendly error messages. This leads to predictable tests and easier debugging.

Together, these Snipps give you a practical roadmap for diagnosing and fixing Azure authentication problems in ASP.NET Core integration tests. If you’re building APIs, background workers, or shared libraries, these tips will help you keep your testing environment clean and Azure-free—unless you want it to talk to Azure.

When you run an ASP.NET Core API from the command line, it will not use the port defined in launchSettings.json. This often surprises developers, but it is normal behavior.
The reason is simple: launchSettings.json is only used by Visual Studio or other IDEs during debugging.
To make your app listen on a specific port when running with dotnet run or dotnet MyApi.dll, you must configure the port using runtime options such as command-line arguments, environment variables, or appsettings.json.

Key Points

• launchSettings.json does not apply when starting the app from the console.
• Use dotnet run --urls "http://localhost:5050" to force a port.
• Or set an environment variable:
  ASPNETCORE_URLS=http://localhost:5050
• For a permanent app-level setting, use appsettings.json to define Kestrel endpoints.
• Use http://0.0.0.0:5050 if running inside Docker or WSL.

When creating API endpoints in ASP.NET Core, you often need to ensure only authenticated users can access certain actions.
The [Authorize] attribute makes this easy — it automatically blocks unauthenticated requests.

Sometimes, you also load the current user from a database or a user service. In this case, it’s a good practice to add a null check as an extra safety step, even if [Authorize] is already applied.

Example

[Authorize]
[HttpPost("DoSomething")]
public async Task<IActionResult> DoSomething(RequestModel request)
{
    var user = await userService.GetContextUserAsync();

    if (user == null)
    {
        // Safety check in case the user is authenticated but not found in the database
        return Unauthorized("User not found.");
    }

    // Continue with the action
    return Ok("Action completed successfully.");
}

Key Ideas

• [Authorize] ensures only authenticated users reach your action.
• If your app looks up users in a database, add an extra if (user == null) check.
• This prevents errors when tokens are valid but the user record no longer exists.

This pattern keeps your API safe, clean, and reliable.

To make your ASP.NET Core services easy to test and maintain, follow this proven pattern. The example below demonstrates how to register a service and configure an HttpClient with custom handlers, while keeping the design flexible for unit testing.

1. Register your service separately

Register your service interface and implementation as a singleton (or other lifetime as needed). This keeps the service replaceable in tests:

services.AddSingleton<IMyService, MyService>();

Tip: Use TryAdd for safe registration in reusable code

If your registration code is part of a shared library or package, use TryAdd to avoid overriding existing registrations accidentally:

services.TryAddSingleton<IMyService, MyService>();

2. Configure an HttpClient with handlers

Use a named HttpClient to add retry and logging handlers. These handlers improve reliability and diagnostics:

services.AddHttpClient(nameof(MyService))
    .AddHttpMessageHandler(s => new RetryHandler(s))
    .AddHttpMessageHandler(s => new LoggingHandler(s));

3. Add memory caching safely

You can call AddMemoryCache() without worry — it internally prevents duplicates:

services.AddMemoryCache();

Full Sample Method:

public static class ServiceCollectionExtensions
{
    public static IServiceCollection AddMyClientServices(this IServiceCollection services)
    {
        ArgumentNullException.ThrowIfNull(services);

        services.AddMemoryCache();

        services.TryAddSingleton<IMyService, MyService>();

        services.AddHttpClient(nameof(MyService))
            .AddHttpMessageHandler(s => new RetryHandler(s))
            .AddHttpMessageHandler(s => new LoggingHandler(s));

        return services;
    }
}

Why This Matters

• Separation of concerns makes your code easier to test.
• Named HttpClient with handlers improves reliability and debugging.
• TryAdd keeps your library safe and reusable.
• Memory cache registration is simple and safe.

Using this approach ensures your ASP.NET Core apps are easier to maintain, test, and extend.

It’s best practice to tailor logging levels per environment (Development, Staging, Production) by using environment-specific configuration files like appsettings.Development.json or appsettings.Production.json.

Example for Development (verbose logging):

{
  "Logging": {
    "LogLevel": {
      "Default": "Debug",
      "Microsoft": "Information",
      "System": "Warning",
      "YourAppNamespace": "Trace"
    }
  }
}

Example for Production (concise logging):

{
  "Logging": {
    "LogLevel": {
      "Default": "Warning",
      "Microsoft": "Warning",
      "System": "Warning",
      "YourAppNamespace": "Information"
    }
  }
}

By adjusting log levels per environment, you can capture detailed diagnostics during development while reducing noise and performance impact in production.

ASP.NET Core allows you to customize logging behavior per provider, such as Console or Application Insights. This is useful when you want different verbosity or volume controls depending on the sink.

Example:

{
  "Logging": {
    "LogLevel": {
      "Default": "Warning",
      "Microsoft": "Warning",
      "System": "Warning",
      "YourAppNamespace": "Trace"
    },
    "Console": {
      "LogLevel": {
        "Default": "Information",
        "YourAppNamespace": "Debug"
      }
    },
    "ApplicationInsights": {
      "LogLevel": {
        "Default": "Error"
      }
    }
  }
}

• Console logs are more verbose for development and debugging (Information and Debug).
• Application Insights only logs errors to reduce telemetry volume and cost.

Use per-provider overrides when you want finer control over logging destinations.

In ASP.NET Core, you can configure logging levels to control the verbosity of logs across your application and third-party frameworks.

A common pattern is to set a default minimum log level (e.g., Warning) and enable verbose logging (Trace) only for your own application namespace.

Example configuration in appsettings.json or an environment-specific file:

{
  "Logging": {
    "LogLevel": {
      "Default": "Warning",
      "Microsoft": "Warning",
      "System": "Warning",
      "YourAppNamespace": "Trace"
    }
  }
}

• "Default": "Warning" sets a baseline for all logs.
• "Microsoft" and "System" are explicitly set to Warning to reduce noise from framework logs.
• "YourAppNamespace": "Trace" enables detailed logging for your application code.

This ensures your app logs detailed information while keeping system logs concise and manageable.