.net - google - refworks download

CLSCompleta(verdadero) arrastra referencias no utilizadas

Question

¿Alguien puede explicar el siguiente comportamiento?

En resumen, si crea múltiples bibliotecas compatibles con CLS en Visual Studio 2008 y les hace compartir una raíz de espacio de nombres común, una biblioteca que haga referencia a otra biblioteca requerirá referencias a las referencias de esa biblioteca aunque no las consuma.

Es bastante difícil de explicar en una sola oración, pero aquí hay pasos para reproducir el comportamiento (preste mucha atención a los espacios de nombres):

Cree una biblioteca llamada LibraryA y agregue una clase única a esa biblioteca:

namespace Ploeh
{
    public abstract class Class1InLibraryA
    {
    }
}

Asegúrese de que la biblioteca sea compatible con CLS agregando [assembly: CLSCompliant(true)] a AssemblyInfo.cs.

Cree otra biblioteca llamada LibraryB y haga referencia a LibraryA. Agregue las siguientes clases a LibraryB:

namespace Ploeh.Samples
{
    public class Class1InLibraryB : Class1InLibraryA
    {
    }
}

y

namespace Ploeh.Samples
{
    public abstract class Class2InLibraryB
    {
    }
}

Asegúrese de que LibraryB también sea compatible con CLS.

Tenga en cuenta que Class1InLibraryB deriva de un tipo en LibraryA, mientras que Class2InLibraryB no lo hace.

Ahora cree una tercera biblioteca llamada LibraryC y haga referencia a LibraryB (pero no a LibraryA). Agregue la siguiente clase:

namespace Ploeh.Samples.LibraryC
{
    public class Class1InLibraryC : Class2InLibraryB
    {
    }
}

Esto todavía debe compilar. Observe que Class1InLibraryC deriva de la clase en LibraryB que no usa ningún tipo de LibraryA .

También tenga en cuenta que Class1InLibraryC se define en un espacio de nombres que forma parte de la jerarquía de espacios de nombres definida en LibraryB.

Hasta ahora, LibraryC no tiene ninguna referencia a LibraryA, y como no usa tipos de LibraryA, la solución compila.

Ahora haga que LibraryC CLS sea compatible también. De repente, la solución ya no se compila, y aparece este mensaje de error:

El tipo ''Ploeh.Class1InLibraryA'' se define en un ensamblaje al que no se hace referencia. Debe agregar una referencia al ensamblado ''Ploeh, Versión = 1.0.0.0, Cultura = neutral, PublicKeyToken = null''.

Puede hacer que la solución vuelva a compilarse de una de las siguientes maneras:

• Eliminar el cumplimiento de CLS de LibraryC
• Agregue una referencia a LibraryA (aunque no la necesite)
• Cambie el espacio de nombres en LibraryC para que no forme parte de la jerarquía de espacios de nombres de LibraryB (por ejemplo, a Fnaah.Samples.LibraryC)
• Cambie el espacio de nombres de Class1InLibraryB (es decir, el que no se usa de LibracyC) para que no se encuentre en la jerarquía de espacios de nombres de LibraryC (por ejemplo, a Ploeh.Samples.LibraryB)

Parece que hay una interacción extraña entre la jerarquía de espacio de nombres y el cumplimiento de CLS.

Se puede resolver este problema seleccionando una de las opciones en la lista anterior, pero ¿alguien puede explicar la razón detrás de este comportamiento?

Answer 1

Eché un vistazo a los documentos oficiales para el CLS ( http://msdn.microsoft.com/en-us/netframework/aa569283.aspx ), pero mi cabeza explotó antes de que pudiera encontrar una respuesta simple.

Pero creo que la base es que el compilador, para verificar el cumplimiento de CLS de LibraryC, necesita buscar posibles conflictos de nombres con LibraryA.

El compilador debe verificar todas las "partes de un tipo que sean accesibles o visibles fuera del ensamblaje definidor" (CLS Regla 1).

Dado que la clase pública Class1InLibraryC hereda Class2InLibraryB, también debe verificar el cumplimiento de CLS con LibraryA, en particular porque "Ploeh. *" Ahora está "dentro del alcance" de la Regla 5 de CLS "Todos los nombres introducidos en un alcance compatible con CLS serán distintos e independientes de amable".

Cambiar el espacio de nombres de Class1InLibraryB o Class1InLibraryC para que se conviertan en distintos parece convencer al compilador de que ya no existe la posibilidad de un conflicto de nombres.

Si elige la opción (2), agrega la referencia y compila, verá que la referencia no está realmente marcada en los metadatos del conjunto resultante, por lo que esta es solo una dependencia de tiempo de compilación / verificación.

Answer 2

El problema se solucionó en Roslyn, que está disponible en Visual Studio 14.
A partir de julio de 2014, el CTP actual está disponible here .
Ver este informe de error para más detalles.

Answer 3

Recuerde que el CLS es un conjunto de reglas que se aplican a los ensamblados generados y está diseñado para soportar la interoperabilidad entre idiomas. En cierto sentido, define el subconjunto común más pequeño de reglas que un tipo debe seguir para garantizar que sea independiente del lenguaje y la plataforma. El cumplimiento de CLS también se aplica a los elementos que están visibles fuera de su conjunto definido.

En cuanto a algunas de las directrices, el código compatible con CLS debe seguir:

• Evite el uso de nombres comúnmente utilizados como palabras clave en los lenguajes de programación.
• No se espera que los usuarios del marco puedan crear tipos anidados.
• Supongamos que las implementaciones de métodos del mismo nombre y firma en diferentes interfaces son independientes.

Las reglas para determinar el cumplimiento de CLS son:

• Cuando un ensamblaje no lleva un System.CLSCompliantAttribute explícito, se asumirá que lleva System.CLSCompliantAttribute (false).
• De forma predeterminada, un tipo hereda el atributo de cumplimiento de CLS de su tipo adjunto (para los tipos anidados) o adquiere el nivel de cumplimiento adjunto a su ensamblaje (para los tipos de nivel superior).
• De forma predeterminada, otros miembros (métodos, campos, propiedades y eventos) heredan el cumplimiento de CLS de su tipo.

Ahora, en lo que concierne al compilador, (CLS Regla 1) debe ser capaz de aplicar las reglas para el cumplimiento de CLS a cualquier información que se exportará fuera del ensamblaje y considera que un tipo es compatible con CLS si todo es público. partes accesibles (aquellas clases, interfaces, métodos, campos, propiedades y eventos que están disponibles para el código que se ejecuta en otro conjunto) o bien

• tener firmas compuestas únicamente de tipos compatibles con CLS, o
• están marcados específicamente como no compatibles con CLS.

Según las reglas de CTS, un ámbito es simplemente un grupo / colección de nombres y dentro de un ámbito, un nombre puede referirse a múltiples entidades siempre que sean de diferentes tipos (métodos, campos, tipos anidados, propiedades, eventos) o tengan firmas diferentes. Una entidad nombrada tiene su nombre en exactamente un ámbito, por lo que para identificar esa entrada deben aplicarse tanto un ámbito como un nombre. El ámbito califica el nombre.

Dado que los tipos tienen nombre, los nombres de los tipos también se agrupan en ámbitos. Para identificar completamente un tipo, el nombre del tipo debe ser calificado por el alcance. Los nombres de los tipos están abarcados por el ensamblaje que contiene la implementación de ese tipo.

Para los ámbitos que son compatibles con CLS, todos los nombres deben ser distintos e independientes del tipo, excepto cuando los nombres son idénticos y se resuelven mediante sobrecarga. En otras palabras, mientras que el CTS permite que un solo tipo use el mismo nombre para un campo y un método, el CLS no (CLS Rule 5).

Un paso más allá, un tipo compatible con CLS no debe requerir la implementación de tipos no compatibles con CLS (Regla 20 de CLS) y también debe heredar de otro tipo de queja CLS (Regla 23 de CLS).

Un ensamblaje puede depender de otros ensamblajes si las implementaciones en el alcance de un ensamblaje hacen referencia a los recursos que están dentro del alcance o son propiedad de otro ensamblaje.

• Todas las referencias a otros conjuntos se resuelven bajo el control del alcance del conjunto actual.
• Siempre es posible determinar en qué ámbito del conjunto se está ejecutando una implementación particular. Todas las solicitudes que se originan en ese ámbito del conjunto se resuelven en relación con ese ámbito.

Lo que todo esto significa en última instancia es que para verificar el cumplimiento de CLS de un tipo, el compilador debe poder verificar que todas las partes públicas de ese tipo también cumplen con CLS. Esto significa que debe garantizar que el nombre sea único dentro de un ámbito, que no dependa de tipos que no cumplan con CLS para partes de su propia implementación y que herede de otros tipos que también sean compatibles con CLS. La única forma de hacerlo es mediante el examen de todos los ensamblajes a los que hace referencia el tipo.

Recuerde que el paso de compilación en Visual Studio es esencialmente una envoltura de GUI para ejecutar MSBuild, que en última instancia no es más que una forma de script para llamar al compilador de línea de comandos C #. Para que el compilador pueda verificar el cumplimiento de CLS de un tipo, debe conocer y poder encontrar todos los ensamblajes que escriben referencias (no el proyecto). Como se llama a través de MSBuild y, en última instancia, de Visual Studio, la única forma en que Visual Studio (MSBuild) le informa de dichos ensamblajes es incluirlos como referencias.

Obviamente, dado que el compilador puede darse cuenta de que está "faltando" las referencias para verificar el cumplimiento de CLS y compilar con éxito, hubiera sido bueno si hubiera podido incluir esas referencias automáticamente en nuestro nombre. El problema aquí es determinar qué versión del ensamblaje incluir y dónde está ese ensamblaje en el sistema de archivos. Al obligar al desarrollador a proporcionar esa información, el compilador ayuda a garantizar que se le proporcione la información correcta. Esto también tiene el efecto secundario de garantizar que todos los ensamblajes dependientes se copien en las carpetas Debug/bin o Release/bin durante la compilación, de modo que estén en el directorio correcto cuando la aplicación se ejecuta después de que se haya compilado.