How to compile a library without locking into specify DLL version-CodePudding

I am developing an open source class library (MySqlBackup.NET) which it can works with 3 optional dependencies that are developed by different developers, but they all have the same ~~namespace~~ type MySqlCommand.

MySQL.DATA.dll
Devart.Data.MySql.dll
MySqlConnector.dll

Each time I released a nuget package, I need to compile 3 times separately with it's specific dependencies.

Is there a way to compile the library that works without needing to bind (locking) the specific target dependency? That it will work if any of the dependant dll that contains the required ~~namespace~~ type exists.

And also, each time when the dependencies had released a new version, I need to recompile again just to match the version number of the dependencies and re-submit new nuget package, but there is actually no code change within my class library.

How to compile the class library that will ignore the version number of the dependencies?

CodePudding user response：

Short answer: no, not in the way you want; the type's identity (in IL) is defined by the assembly and the full type name - you can't just say "this type name, but I don't care where from"

You could perhaps just depend on DbCommand (or more generally: the APIs in System.Data.Common), rather than any provider-specific types; this is usually enough for most ADO.NET work unless you desperately need to touch provider-specific APIs, in which case: you might need to use some form of runtime reflection code (as an example: Dapper uses optimized reflection to tweak Oracle's BindByName behaviour, when it finds it). Note that ADO.NET also has a provider factory model, although it isn't much fun to work with.

Another approach is to have a core library that contains the common/shared logic, and 3 satellite libraries that all depend on that core library, and contain the provider-specific facets (obviously each satellite library would also take a package reference against one of the provider-specific APIs). Due to how transient dependencies work, your average consumer would then just need a single package-reference to their appropriate provider-specific package, for example MySqlBackup.Devart (naming is hard!).