title: How to enable forward compatibility on a reusable .NET library?
body: <p>I'm in the process of creating a new minor release of a <a href="http://simpleinjector.codeplex.com" rel="noreferrer">toy project</a> of mine. This project is released on NuGet and is compatible with .NET 4.0 and up. Some of the new features I'm introducing require .NET 4.5 (users should be able to resolve <code>IReadOnlyCollection&lt;T&gt;</code> and <code>IReadOnlyList&lt;T&gt;</code>, both interfaces that were introduced in .NET 4.5), but I need to keep the project compatible with .NET 4.0, since not all developers can easily migrate to the latest .NET framework.</p>
  
  <p>So the problem I’m facing is how to solve this ‘forward-compatibility’ problem. There are two solutions I’ve thought about, but both are not very attractive, so hopefully anybody can give me some ideas or guidance here.</p>
  
  <p>Here are the two solutions I came up with:</p>
  
  <p>Solution 1: Use <code>#if</code> compiler directives and build a DLL per .NET framework version and ship those versions using the NuGet packages and download at the project site.</p>
  
  <p>Downside of this method is that when developers update their Visual Studio project from .NET 4.0 to .NET 4.5, they don't automatically get the .NET 4.5 version (with .NET 4.5 specific features). This violates the <a href="https://en.wikipedia.org/wiki/Principle_of_least_astonishment" rel="noreferrer">Principle of least astonishment</a> and would leave developers dazed why the feature is not working, when they try using it a few months later.</p>
  
  <p>Solution 2: Use one single DLL and emit type's on the fly that implement both new interfaces when they exist in the current app domain. This allows shipping a single DLL to the user and allows features to come available when the developer switches .NET framework versions in their project. This will make things 'just work'. This is the direction I’m currently heading btw.</p>
  
  <p>Since I need to return a type that needs to implement the interfaces, the downside is that that type must be created at runtime using Reflection.Emit, ModuleBuilder, TypeBuilder, and the like. This is seriously nasty shizzle. But besides that, since this type must be created in a new (anonymous) assembly, I must make some internal types public (a type it needs to inherit from and an interface it needs to implement). Making those internal types public pollutes the API of the project and will disallow me from making changes to those types.</p>
  
  <p>I believe these are my options, but I might be missing something obvious. So my question is, am I missing a possibility? Is there a way to circumvent the problems for solution 1 or would it be better to go with the hardcore root of runtime type emitting?</p>