Support overriding library version#3125
Conversation
| static StackExchange.Redis.Configuration.DefaultOptionsProvider.ComputerName.get -> string! | ||
| static StackExchange.Redis.Configuration.DefaultOptionsProvider.GetProvider(StackExchange.Redis.EndPointCollection! endpoints) -> StackExchange.Redis.Configuration.DefaultOptionsProvider! | ||
| static StackExchange.Redis.Configuration.DefaultOptionsProvider.GetProvider(System.Net.EndPoint! endpoint) -> StackExchange.Redis.Configuration.DefaultOptionsProvider! | ||
| static StackExchange.Redis.Configuration.DefaultOptionsProvider.LibraryVersion.get -> string! |
There was a problem hiding this comment.
@mgravell is there any chance this change is "okay"? I really want to change LibraryVersion from a protected static to public virtual, but that means removing this line from the shipped API.
If this is too much of a break, I can either a) leave the static and add a new instance property with a different name, or b) have the extension package set ConfigurationOptions.LibraryVersion directly rather than bubbling it up form its custom DefaultOptionsProvider. But that's a weird divergence from the other options and risks interacting with customers' use of ConfigurationOptions.LibraryVersion
There was a problem hiding this comment.
The problem isn't changing the shipped file - the problem is the MissingMethodException etc at runtime when someone builds against one version and gets given another - this applies doubly for libraries that package SE.Redis such as azure. I think maybe the right thing here is to accept a sucky name for a new member.
|
This gets awkward when multiple libraries think they're king. For example, NRedisStack also tries hard to mess with this. We discussed this about a year ago: #2937 - is it perhaps worth us resurrecting that sort of approach, perhaps with better defaults-provider support? |
2 participants
Allow customizing the reported library version via a DefaultOptionsProvider. Intended for use by the Microsoft.Azure.StackExchangeRedis extension package because knowing the extension's version is usually more helpful than the SE.Redis version when diagnosing issues customers are having.
This PR also aligns behavior of LibraryName with other ConfigurationOptions properties in terms of defaulting to a value from the current DefaultOptionsProvider.