Snippset Feed

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.

Creating reliable HTTP client services is a challenge for many .NET developers. Network timeouts, throttling, retries, and unexpected exceptions often lead to inconsistent logging, unclear error messages, and unstable public APIs. This Snipp gives an overview of how to design a clean, predictable, and well-structured error-handling strategy for your HTTP-based services.

Readers will learn why custom exceptions matter, how to log different failure types correctly, and how to build a stable exception boundary that hides internal details from users of a library. Each child Snipp focuses on one topic and includes practical examples. Together, they offer a clear blueprint for building services that are easier to debug, test, and maintain.

The overall goal is simple: Create a .NET service that logs clearly, behaves consistently, and protects callers from internal complexity.

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.

TRUNCATE TABLE Explained

The SQL command TRUNCATE TABLE removes all rows from a table at once — quickly and efficiently.
Unlike DELETE, which deletes rows one by one, TRUNCATE empties the entire table without affecting its structure.

That means columns, data types, indexes, and permissions remain intact — only the data is gone.

When to Use TRUNCATE

Use TRUNCATE TABLE when

• you want to clear all data from a table,
• you don’t need a WHERE clause, and
• speed matters.

Example:

TRUNCATE TABLE customers;

This command instantly removes all records from the customers table while keeping the table ready for new data.

Key Differences: TRUNCATE vs. DELETE

Important Notes

• You cannot truncate a table that is referenced by a foreign key.
• In most databases, TRUNCATE is treated as a DDL command (Data Definition Language), like CREATE or DROP.
• Best practice: use TRUNCATE for temporary or helper tables where you’re certain the data can be safely removed.

Retrieving data from a URL or calling a web API is one of the most common PowerShell tasks. Whether you want to check a website’s status, download a file, or interact with a REST API, PowerShell provides built-in commands for this purpose.

1. Using Invoke-WebRequest

Invoke-WebRequest is used to fetch web pages or files.
Example:

$response = Invoke-WebRequest -Uri "https://example.com"
$response.Content

This command returns the full HTTP response, including status code, headers, and body content.

To download a file:

Invoke-WebRequest -Uri "https://example.com/file.zip" -OutFile "C:\Temp\file.zip"

2. Calling APIs with Invoke-RestMethod

For APIs that return JSON or XML, Invoke-RestMethod is the better choice. It automatically converts the response into PowerShell objects:

$data = Invoke-RestMethod -Uri "https://api.github.com"
$data.current_user_url

You can also send POST requests:

Invoke-RestMethod -Uri "https://api.example.com/data" -Method POST -Body '{"name":"John"}' -ContentType "application/json"

3. Running PowerShell from the Command Line

PowerShell commands can be executed directly from the traditional Windows Command Prompt:

powershell -Command "Invoke-WebRequest -Uri 'https://example.com'"

Or, if available, using curl:

curl https://example.com

Summary

With just a few commands, PowerShell becomes a versatile tool for web requests and API communication — ideal for automation, system monitoring, or accessing online data sources.

When an IP address no longer requires access, delete its firewall rule to maintain a secure environment.

Delete a server-level rule:

EXECUTE sp_delete_firewall_rule @name = 'AllowOfficeIP';

Delete a database-level rule:

EXECUTE sp_delete_database_firewall_rule @name = 'AllowDevMachine';

If you encounter issues deleting rules (for instance, due to missing permissions), ensure you’re connected with sufficient administrative rights or use the Azure Portal for manual removal.

Source: Microsoft Docs – sp_delete_database_firewall_rule

To check which IP addresses have access to your Azure SQL Database, use the following T-SQL queries:

To list server-level firewall rules:

SELECT * FROM sys.firewall_rules;

To list database-level firewall rules:

SELECT * FROM sys.database_firewall_rules;

This helps verify which IP ranges currently have access and ensures that no outdated or overly broad rules are active. Regular audits of firewall rules are essential for maintaining data security.

Source: Todd Kitta GitHub – Configure Firewall Settings T-SQL