"Paquete de compatibilidad" para backporting nuevas características de .NET Framework?

Question

Por diversas razones, a menudo me parece deseable escribir código que sea compatible con .NET framework 2.0 o 3.5 o compatible con .NET Compact Framework, pero es un problema que haya numerosas características "pequeñas" en los nuevos .NET frameworks que no están disponibles en los marcos anteriores o Compact Framework.

Por ejemplo, creo que los métodos de extensión son realmente útiles, pero el compilador depende de System.Runtime.CompilerServices.ExtensionAttribute para esto. Puede definir fácilmente este atributo usted mismo y luego usar métodos de extensión en .NET Framework 2.0 (bajo C# 3.0+). Del mismo modo, no es demasiado difícil definir manualmente pequeños tipos de .NET 4 como Tuple<T1,T2> y Lazy<T>. Por cierto, si quiere usar LINQ en .NET 2.0, puede usar LinqBridge.

Supongamos ahora que hace público el ExtensionAttribute para que otros ensambles que escriba puedan usarlo. Eso está bien al principio, pero ¿y si luego quieres usar una biblioteca de terceros que también tuviera la misma idea? Agrega una referencia a esa biblioteca y ahora tiene una colisión de nombre. Oops.

También he notado que algunas nuevas bibliotecas solo están disponibles para .NET 4.0 o 3.5, aunque solo tienen dependencias menores que podrían resolverse usando un paquete de compatibilidad o LinqBridge.

Sería bueno si hubiera "paquetes de compatibilidad" para versiones anteriores de .NET que definieran estas pequeñas características en una pequeña DLL que podría justificar incluso en proyectos de cualquier tamaño. ¿Existe tal cosa?

Actualización: A juzgar por el silencio, supongo que no existe tal cosa. Podría crear una biblioteca de OSS así si hubiera interés. Así que mi nueva pregunta es, ¿qué características de más pequeñas de .NET 4 (en comparación con monstruos como WCF/WPF) se perdería si estuviera escribiendo para .NET 2, .NET 3.5, .NETCF o Silverlight? Voy a empezar la lista de ...

• ExtensionAttribute (no en .NET 2)
• Func<...>Action<...> y delegados (no en .NET 2)
• LINQ a objetos (no en. NET 2)
• Tuple<...> (no en .NET 3,5)
• Lazy<T> y Lazy<T,TMetadata> (no en .NET 3.5)
• árboles de expresión (no en .NET 2; incompleta en .NET 3.5)
• Varianza genérica (existe en .NET 2 pero inaccesible desde C# 3 y VB 9)
• Reflection.Emit (falta en .NETCF; no es realmente una característica pequeña, pero lo extraño mucho)

Answer 1

Bibliotecas de Theraot

Usted puede utilizar el uso de Theraot.CoreTheraot's Libraries acondicionarlo una gran porción de código .NET para versiones antiguas comenzando con .NET 2.0 gracias a la compilación condicional.

Fuera de las características mencionadas, se incluyen los siguientes: objetos LINQ a

• ExtensionAttribute
• Func<...> y Action<...> delegados
• Tuple<...>
• Lazy<T> y Lazy<T,TMetadata>
• Expresión Tre ss

También se incluyen las siguientes características que no se mencionan en la pregunta: ¿

• HashSet<T>
• SortedSet<T>
• ThreadLocal<T>
• IObservable<T> y IObserver<T>
• BigInteger
• ConcurrentDictionary<Tkey, TValue>
• etc ...

Nota: No se prevé apoyo para System.Threading.Tasks.

Lamentablemente, solo hay poca documentación disponible en el momento de la escritura, sin embargo, cualquier diferencia en el comportamiento del BCL puede considerarse un error, y puede ser reported via github.

Answer 2

No sé qué tan útil será una lista así, ya que es potencialmente monstruosa en tamaño. El CLR es el mismo para 2.0, 3.0 & 3.5 por lo que técnicamente cualquiera de estas características posteriores a 2.0 podría convertirse en un "paquete de compatibilidad".

-Oisin

Answer 3

Esto no es realmente un "paquete de compatilibity", pero ya que ha mencionado LinqBridge ... otra "característica portado" lo uso con frecuencia son las extensiones que se encuentran paralelas (entre otras cosas) en el Reactive Extensions (Rx) para Framework 3.5 SP1 (en System.Threading.dll).Incluye la implementación completa de la Biblioteca de tareas paralelas y el LINQ paralelo (PLINQ).

Para .Net 4.0 existe el Async Targeting Pack for Visual Studio 2012 (nuget) de Microsoft. Que proporciona muchos métodos de extensión Async y proporciona soporte para las palabras clave async/await si usa el compilador C# 5.

Similarmente para .Net 3.5 está el AsyncBridge que se basa en la biblioteca TPL de las Extensiones reactivas para proporcionar async/await. También hay una versión de AsyncBridge para .Net 4.0, pero no estoy seguro de por qué querrías esa por encima de la de Microsoft.

Answer 4

Para .NET 3.5 puede usar FSharp.Core.dll desde el F # Runtime para .NET Framework 2.0.

"La biblioteca de núcleo (FSharp.Core.dll) incluidos en este paquete redistribuible contiene algunas APIs en los espacios de nombres del sistema que son idénticos a .NET Framework 4 APIs que se requieren para F # desarrollo."

http://msdn.microsoft.com/en-us/library/ee829875%28v=vs.100%29.aspx

Esto incluye System.Tuple et al y System.Lazy<T> (No Lazy<T,TMetadata> aunque.) Para usarlos simplemente referencia FSharp.Core.dll

Editar:... Resulta Lazy en FSharp.Core.dll es no es un reemplazo directo, sino más bien una clase interoperativa. Tiene las mismas propiedades pero no los mismos constructores. Más bien se creó, por ejemplo, así:

Lazy<string> lazy = Microsoft.FSharp.Control.LazyExtensions.CreateFromValue("test");