I have an asynchronous library which is compiled under .NET 3.5, since it’s used by .NET 3.5 applications, but I want to be able to deal with .NET 4.0 CancellationTokens if someone wants to pass one in. In order to include .NET 4.0 stuff, I have to break compatibility with .NET 3.5. The only option I’ve come up with so far would be to just allow passing in “object” and then use reflection, but that makes for an ugly public interface… I want to make sure the client code is passing in the correct object type at compile time, not runtime.
Is there any way to bind against .NET 4.0 objects at compile time, without introducing an unnecessary dependency to consumer applications? To say “use this feature if it’s there, and skip it if it’s not”?
You could have the public interfaces that require .NET 4.0 types in a separate assembly, possibly as Extension methods – and if you need to (e.g. interact between the .NET 4 types and the internals of your types in the main assembly) you could define an interface in your main (.NET 3.5) assembly and implement it in the .NET 4 assembly with a wrapper around a .NET 4 type in order to avoid reflection entirely.