Pregunta

¿Es posible crear una biblioteca que se pueda consumir desde .Net 2.0 y también permita a los consumidores .Net 3.0+ beneficiarse de DataContracts si lo desean?

No veo ningún obstáculo técnico para esto que no sea la biblioteca que contiene los diferentes atributos relacionados con DataContract es una biblioteca .Net 3.0. ¿Se pueden implementar estos atributos manualmente de forma similar a ExtensionMethodAttribute?

¿Fue útil?

Solución

Si agrega atributos .NET 3.0 a un ensamblaje, ejecútelo solo en una máquina con .NET 2.0, esto equivale a tener un atributo en su código de un ensamblaje que no está disponible en tiempo de ejecución.

Esto generalmente funcionará bien siempre que la aplicación .NET 2.0 en realidad no intente leer los atributos. Por ejemplo, el siguiente código arrojará una FileNotFoundException porque no podrá cargar System.ServiceModel.dll si se ejecuta en una máquina con .NET 2.0:

[ServiceContract] // Attribute from System.ServiceModel.dll
class MyClass
{
  ...
}
...
    // this will throw a FileNotFoundException if System.ServiceModel.dll is not available
    object[] attributes = typeof(MyClass).GetCustomAttributes(false);

Por lo tanto, si no sabe quién consumirá su biblioteca de clases, no puede garantizar al 100% que no los romperá.

Lo anterior se puede evitar enviando una copia de System.ServiceModel.dll (u otro conjunto que contenga atributos que esté usando) con su aplicación, o (creo) usando la sobrecarga de GetCustomAttributes que toma un System.Type argumento, por lo que solo lee los atributos que se sabe que están disponibles.

Otros consejos

Dado que .NET 2.0 y .NET 3.0 y 3.5 usan el mismo CLR (2.0), no debería tener ninguna dificultad.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top