Each time I deal with a binding attribute, my brain goes into fear mode.
For example, spend hours on this property that I was providing:
Connection - with a tooltip that says
Gets or sets the app setting name that contains the connection string
Which as some context when viewed from text specified in the interface:
BUT ALMOST EVERYONE DOES NOT VIEW THE PROPERTY FROM THE INTERFACE! Which yields this moment of joy:
However, what is actually specified is the ConnectionNAME rather than just an ambiguous term of "Connection"
Now, a configuration name is typically provided from the root object using a separator as you increase the depth of the namespace, where the separator for the environment is defined(i typically use ":").
So for hours that was my assumption - but that too is not true. This property does NOT use the root, it uses the prefix of "ConnectionStrings" which I don't believe is mentioned anywhere, including the error message that is provided:
and that is because it's NOT starting at the root! A better message IMO would be, Attempting to retrieve the connection string via "ConnectionStrings:XXXXX" which cannot be found (where XXX is the default or the provided value).
That would AT LEAST tell me that it's NOT looking a Values, as I plugged this name in everywhere in hopes that I understand the configuration path the code is using.
Perhaps this property is better called ConnectionNameInConnectionStringsSection ...
I would also like to advocate an alternate constructor to properly reflect the requirements of a configuration associated with Azure Service bus which is "Namespace", "SharedAccessKeyName", "SharedAccessKey" (as i had encoding those values in a connection string - which if i must, I use a template to do so - but that too is not possible with this attribute). Another one for Managed Identity (following DefaultAzureCredentials pattern perhaps?)
As my configuration specification for an Azure Service bus is in this following structure - where all subscriptions for a Topic are also provided.
Other questions:
How can we inject/alter Configuration providers before the binding?
The binding is just cheater code to set up a web job using IHostedService - perhaps the sample can show how the ServiceBusAttribute gets to this point? Which would allow much more configuration for a professional developer that understands configuration and dependency injection?
Each time I deal with a binding attribute, my brain goes into fear mode.
For example, spend hours on this property that I was providing: Connection - with a tooltip that says
Gets or sets the app setting name that contains the connection string
Which as some context when viewed from text specified in the interface:
BUT ALMOST EVERYONE DOES NOT VIEW THE PROPERTY FROM THE INTERFACE! Which yields this moment of joy:
However, what is actually specified is the ConnectionNAME rather than just an ambiguous term of "Connection"
Now, a configuration name is typically provided from the root object using a separator as you increase the depth of the namespace, where the separator for the environment is defined(i typically use ":").
So for hours that was my assumption - but that too is not true. This property does NOT use the root, it uses the prefix of "ConnectionStrings" which I don't believe is mentioned anywhere, including the error message that is provided:
and that is because it's NOT starting at the root! A better message IMO would be, Attempting to retrieve the connection string via "ConnectionStrings:XXXXX" which cannot be found (where XXX is the default or the provided value).
That would AT LEAST tell me that it's NOT looking a Values, as I plugged this name in everywhere in hopes that I understand the configuration path the code is using.
Perhaps this property is better called ConnectionNameInConnectionStringsSection ...
I would also like to advocate an alternate constructor to properly reflect the requirements of a configuration associated with Azure Service bus which is "Namespace", "SharedAccessKeyName", "SharedAccessKey" (as i had encoding those values in a connection string - which if i must, I use a template to do so - but that too is not possible with this attribute). Another one for Managed Identity (following DefaultAzureCredentials pattern perhaps?)
As my configuration specification for an Azure Service bus is in this following structure - where all subscriptions for a Topic are also provided.
Other questions: How can we inject/alter Configuration providers before the binding? The binding is just cheater code to set up a web job using IHostedService - perhaps the sample can show how the ServiceBusAttribute gets to this point? Which would allow much more configuration for a professional developer that understands configuration and dependency injection?