versiones quitar paquete office modo mantener desactivar cómo con compatibilidad como casilla archivo anteriores activa abrir c# .net frameworks nuget framework-design

c# - quitar - ¿Cómo habilitar la compatibilidad con versiones anteriores en una biblioteca.NET reutilizable?



paquete de compatibilidad office 2016 (2)

¿Has pensado en otro ensamblaje personalizado con los elementos faltantes? Luego, prueba si existe un tipo / método (que solo existiría en .net 4.5) y si lo hace, cargue el ensamblado en.

De esa forma puedes mantener exactamente los mismos métodos y clases, y ahorrarte el dolor de hacer toda esa loca emisión (sin mencionar el golpe de perfomance que tomarás si te encuentras haciendo tanto).

Estoy en el proceso de crear un nuevo lanzamiento menor de un proyecto de juguete mío. Este proyecto se lanzó en NuGet y es compatible con .NET 4.0 y versiones posteriores. Algunas de las nuevas características que estoy presentando requieren .NET 4.5 (los usuarios deberían poder resolver IReadOnlyCollection<T> y IReadOnlyList<T> , ambas interfaces que se introdujeron en .NET 4.5), pero necesito mantener el proyecto compatible con .NET 4.0, ya que no todos los desarrolladores pueden migrar fácilmente al último .NET framework.

Entonces, el problema al que me estoy enfrentando es cómo resolver este problema de "compatibilidad con versiones anteriores". Hay dos soluciones en las que he pensado, pero ambas no son muy atractivas, así que espero que alguien me pueda dar algunas ideas u orientación aquí.

Estas son las dos soluciones que se me ocurrieron:

Solución 1: use #if directivas de compilación y #if una DLL por versión de .NET framework y envíe esas versiones usando los paquetes NuGet y descargue en el sitio del proyecto.

La desventaja de este método es que cuando los desarrolladores actualizan su proyecto de Visual Studio desde .NET 4.0 a .NET 4.5, no obtienen automáticamente la versión de .NET 4.5 (con características específicas de .NET 4.5). Esto viola el Principio de menor asombro y deja a los desarrolladores aturdidos por qué la característica no funciona, cuando intentan usarla unos meses después.

Solución 2: use una sola DLL y emita sobre la marcha tipos que implementen ambas interfaces nuevas cuando existan en el dominio actual de la aplicación. Esto permite enviar una única DLL al usuario y permite que las funciones estén disponibles cuando el desarrollador cambie las versiones de .NET Framework en su proyecto. Esto hará que las cosas ''solo funcionen''. Esta es la dirección que estoy dirigiendo por cierto.

Como necesito devolver un tipo que necesita implementar las interfaces, la desventaja es que ese tipo debe crearse en tiempo de ejecución usando Reflection.Emit, ModuleBuilder, TypeBuilder, y similares. Esto es muy desagradable. Pero además de eso, dado que este tipo debe crearse en un nuevo ensamblado (anónimo), debo hacer que algunos tipos internos sean públicos (un tipo del que necesita heredarse y una interfaz que necesita implementar). Hacer públicos esos tipos internos contamina la API del proyecto y me impedirá realizar cambios en esos tipos.

Creo que estas son mis opciones, pero me podría estar perdiendo algo obvio. Entonces mi pregunta es, ¿me estoy perdiendo una posibilidad? ¿Hay alguna forma de eludir los problemas de la solución 1 o sería mejor seguir con la raíz hardcore del tipo de ejecución?


Tengo un proyecto llamado Dynamitey que le permite cargar un tipo en tiempo de ejecución y llamó a sus métodos estáticos y constructores con el DLR. Que sería mucho menos sucio que una gran cantidad de reflexión o emisión de código para cargar una API que no está necesariamente disponible.

dynamic bigIntType = new DynamicObjects.LateType("System.Numerics.BigInteger, System.Numerics, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"); if (bigIntType.IsAvailable) { var one = bigIntType.@new(1); var two = bigIntType.@new(2); Assert.IsFalse(one.IsEven); Assert.AreEqual(true, two.IsEven); var tParsed = bigIntType.Parse("4"); Assert.AreEqual(true, tParsed.IsEven); }

También tengo un proyecto llamado ImpromptuInterface , que emitirá tipos de proxy para las interfaces en torno a los objetos que incluyen el DLR.

var targetType =Type.GetType("System.Collections.Generic.IReadOnlyList`1[[System.String, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]], mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"); var list = new List<string>{"lala", "la","lala"}; object readonlyList; if(targetType != null){ readonlyList = Impromptu.DynamicActLike(list, targetType); }