SqlClient: SQLConnectionStringBuilder 5.0 is not Backwards Compatible with appSettings.json

Describe the bug

With SqlClient 4, standard appSettings.json standard config file mapping from something like { "MyDb": { "Components": { "UserID": "blah", "Password": "foo", "DataSource": "hostname", "Encrypt": false } } } to a SQLConnectionStringBuilder property worked. With SqlClient 5.0, the resulting connection string is now returning Encrypt=True

I’ve tried changing encrypt value in json to “false”, “False”, “SqlConnectionEncryptOption.Optional”, and “Optional”. All of those still result in connection string with Encrypt=True.

To reproduce

    public class SqlConnectionString
    {
        public SqlConnectionStringBuilder Components { get; set; } = new();

        public override string ToString()
        {
            return Components.ConnectionString;
        }
    }

    public class Settings
    {
        [Required]
        public SqlConnectionString? MyDb { get; set; }
    }
            hostBuilder.ConfigureServices((ctx, services) =>
            {
                    var configuration = ctx.Configuration;
                    services.Configure<Settings>(configuration);
                    var settings = configuration.Get<Settings>();
                    Assert.Contains("Encrypt=false", settings.MyDb.ToString());
            }

Expected behavior

Expecting appSettings.json (or environment variable override of it) setting of “Encrypt”: false to result in Encrypt=false in resulting connection string.

Further technical details

Microsoft.Data.SqlClient version: 5.0.1 .NET target: 6 SQL Server version: n/a Operating system: Windows 10

Additional context We’re using the SqlConnectionStringBuilder to assemble/validate connection string components that are coming from different places (environment variables in helm chart, Azure keyvault, appSettings.json) into a single connection string. Our environment doesn’t yet support encrypt=true/mandatory.

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Comments: 17 (12 by maintainers)

Most upvoted comments

Oh I see, via the implicit casting operator.

I’m pretty sure you may find some other cases when arbitrary classes in connection strings won’t work well. For example, people sometimes bind a Winforms PropertyGrid (I think that’s what it’s called) to a connection string builder, to allow users to manipulate the settings etc. This works with the primitive types, but I’m not sure it would work well with arbitrary classes. VS DDEX may be another problem.

Could some serilisation hints be added?