Add nullable annotations

[maxkoshevoi]

Please, add support for nullable reference types to these packages.

Microsoft.Extensions.* dependencies should be annotated in .Net 7 (not all of them are annotated so far)

[zhiyuanliang-ms]

Maksym Koshovyi (@maxkoshevoi) Where do you want to have nullable reference types?

Is there any use case/scenario where nullable reference would be very helpful for you? Could you provide a code snippet?

[maxkoshevoi]

Zhiyuan Liang (@zhiyuanliang-ms) Here's an example where they would be helpful. This is the example code from this repository. If I launch it and don't have a connection_string in appsettings.json file, I get a NRE. With nullable reference types there would be a warning that options.Connect() doesn't allow nulls, and settings["connection_string"] might be null

var builder = WebApplication.CreateBuilder(args);
builder.Host.ConfigureAppConfiguration((hostingContext, config) =>
{
    var settings = config.AddJsonFile("appsettings.json").Build();
    config.AddAzureAppConfiguration(options =>
    {
        options.Connect(settings["connection_string"]);
    });
});
builder.Services.AddAzureAppConfiguration();

var app = builder.Build();
app.UseAzureAppConfiguration();

app.Run();

[zhiyuanliang-ms]

Hi, Maksym Koshovyi (@maxkoshevoi) Thank you for the response.

If I launch it and don't have a connection_string in appsettings.json file, I get a NRE.

This is expected, isn't it? Are you suggesting that we should not throw exception when connection string is null/empty, instead, we should just log warning and do nothing?

BTW, could you make your code like this by having null check for connection string before call AddAzureAppConfiguration.

[maxkoshevoi]

Are you suggesting that we should not throw exception

Not at all, exception is what I would expect in this situation. No behavioral changes are needed.
I'm suggesting that there should be a warning telling the user that there's a possible NRE since IConfigurations indexer is already telling the compiler that it might return null

The only thing left is to tell compiler that options.Connect() doesn't expect null as a first argument.

All nullable reference types do is give the compiler additional information, so that it can warn users of potential NREs at compile time. Like so:

BTW, could you make your code like this by having null check for connection string before call AddAzureAppConfiguration.

In this case there won't be an NRE (and if nullable reference types were to be enabled in this package the compiler also wouldn't show the warning, where in the previous example it would which would encourage the user to add the if you mentioned to check connection string for null beforehand)

[maxkoshevoi]

I can create the PR for this issue if it's okay

[zhiyuanliang-ms]

Hi, Maksym Koshovyi (@maxkoshevoi)

I can create the PR for this issue if it's okay

That will be great! Thank you so much.

[maxkoshevoi]

Zhiyuan Liang (@zhiyuanliang-ms) could you take a look at the PR please?

[zhiyuanliang-ms]

Maksym Koshovyi (@maxkoshevoi) Sure. I was distracted by some other tasks. I didn't put my main focus on .NET provider. I will take a look this RP once I finish my current tasks.

[zhiyuanliang-ms]

Hey, Maksym Koshovyi (@maxkoshevoi)

I get a NRE. With nullable reference types there would be a warning that options.Connect() doesn't allow nulls, and settings["connection_string"] might be null

But actually, we've already handled the NRE, we will check whether connection string is null, if yes, we throw argument null exception.

[linglingye001]

Hi Maksym Koshovyi (@maxkoshevoi) , thanks for this suggestion and the PR.

1. All potential NREs are already wrapped as ArgumentNullException
   All public API entry points (e.g., Connect()) with a descriptive parameter name when null or empty values are passed.
2. Established coding convention — consistent with the Azure .NET SDK ecosystem
   Our codebase follows the same convention used across all .NET Azure SDKs, nullable is disabled at the project level. We want to maintain a consistent code style across our public and internal C# codebase. Changing this convention in just our library would create inconsistency with the broader ecosystem our customers depend on.
3. Nullable annotations are compile-time hints, not runtime safety
   string? annotations help the compiler surface warnings, but they do not provide runtime protection. A caller with NRT disabled (which is still the default for most .NET projects) would receive no warning at all.
4. Example projects now include null checks
   We've heard the feedback about the example code. We've added explicit null/empty validation for connection strings and endpoints in all example projects

We're closing this issue as the underlying concerns have been addressed through runtime null checks in the library and improved examples. Thank you again for your contribution!