How could the driver surface the connection string dictionary keys and their metadata?

[shueybubbles]

Today, the only way to get a description of a property one can use in the connection string is from the TypeDescriptor associated with each public property of SqlConnectionStringBuilder. Is that correct?
I'd like to be able to work with the connection string builder purely through its IDictionary interface, for a few reasons:

1. To avoid needing to use reflection/TypeDescriptor, and
2. So my app can index the dictionary using constants provided by the driver instead of duplicating the values from DbConnectionStringKeywords in my own code, and
3. So I can build a dynamic connection string builder UI that works with any DbConnectionStringBuilder instance without hard coding all the properties.

For example - If I could enumerate the set of allowed keys in the dictionary, I can wrap the dictionary with an ObservableDictionary instance as the basis of a view model for a XAML UI. Having the associated metadata for each key would let me show the user the description of the property and enable a DataTemplate approach to create an editor for each value. Whenever the driver adds a new property I wouldn't have to change the code of my connection editor.

I understand such a UI would still want to special case a few properties to hide them or to have a specialized editing experience for certain groups of properties, but the general concept of programmatic discovery of semantics would still be valuable.

[roji]

Why are you trying to avoid using reflection/TypeDescriptor? That would be the natural way to do something like this.

[shueybubbles]

There's a performance overhead to invoking property getters and setters through reflection instead of just setting the values directly through IDictionary. There's no way I know of to map the C# property name to the correct dictionary key; I don't think every C# property name is a synonym for its corresponding dictionary key. If the property names are indeed all synonyms for the dictionary then it's not as bad as I thought.

There's a general concern about wanting to use the least specific set of interfaces for interop between components. Some code might want to pass the IDictionary around instead of SqlConnectionStringBuilder or DbConnectionStringBuilder. Having a static function somewhere that can map a dictionary key to relevant metadata could be useful for clients that don't want to deal with TypeDescriptor et al. Granted there's still coupling of such code to SqlClient.

[roji]

There's a performance overhead to invoking property getters and setters through reflection instead of just setting the values directly through IDictionary.

I think there's some confusion here - actually reading and writing the values can simply be done via IDictionary, without requiring any reflection. However, knowing which properties actually exist on a given DbConnectionStringBuilder (e.g. SqlConnectionStringBuilder) can be done via reflection; you'd look for all properties with [DisplayName] on them, with the attribute's value being the key name for that property. This would all be a one-time discovery thing which you'd execute at startup and then cache the results. There shouldn't be any meaningful performance overhead to using reflection.

[shueybubbles]

I didn't realize the DisplayName attribute provided the dictionary keys, thx.

Considering my code is going to be compile-time bound to a particular SqlClient version for the foreseeable future, I can put the code that builds the mapping of C# property names to dictionary keys into a C# source generator project so there's no runtime impact.

[roji]

@shueybubbles there really shouldn't be a reason to use source generators here, over simply using reflection once to discover the attributes and then caching the information. There's nothing wrong with using reflection in this way - I'd recommend avoiding premature optimization.

[shueybubbles]

I'm trying to move more of our code to be runnable in JIT-free environments. I know SqlClient itself is a long way from being AoT friendly, but there's no reason to add to the debt.

[roji]

Using reflection to go over a type's properties and check attributes on them does not require a JIT.

[shueybubbles]

good point, I still had it in my head that I was going to be dealing with MethodInfo instances.

[roji]

Sure. MethodInfo instances are also fine in general; to avoid requiring JIT (i.e. to be NativeAOT-compatible), you need to avoid APIs which generate code at runtime - this means stuff like MethodInfo.MakeGenericMethod (to generate a closed generic method from an open definition), Type.MakeGenericType. Even invoking a MethodInfo in runtime can be fine - you just need to be sure that the linker sees that invocation and that code for the method gets generated.

Note that there are also trimming concerns here, i.e. you need to make sure things aren't trimmed out because they're not referenced in the application. But trimming-related attributes can make sure the appropriate things are preserved; for example, if you have an API that accepts an Type parameter which represents a DbConnectionStringBuilder, you can put an attribute on that parameter to instruct the linker to preserve all properties on it.

In other words, there's no need to start avoiding reflection per-se in all scenarios - just to be aware of what kind of reflection use is problematic etc.