Como ya había dicho anteriormente, hay un sin fin de lenguajes con los que se pueden programar en .NET, pero no todos siguen las mismas reglas, por ejemplo, hay unos que son case-sensitive(ie:C#) y otros case-insensitive (VB) ... Imaginad que escribo una librería .dll en C# y mi cliente la usará en su proyecto ASP.NET en VB (mis dos enemigos juntos xD) ..., imaginad que en esa librería he incluido dos métodos públicos con mismo nombre y parámetros que se diferencian en que uno empieza por mayúsculas y otro en minúsculas ... ¿que pasaría al abrirlo con VB? Pues que no podría diferenciarlo.
Para esto existe el CLS (Common Language Specification), que "...es una especificación estandarizada que describe un entorno virtual para la ejecución de aplicaciones, cuya principal característica es la de permitir que aplicaciones escritas en distintos lenguajes de alto nivel puedan luego ejecutarse en múltiples plataformas tanto de hardware como de software sin necesidad de reescribir o recompilar su código fuente..." (Vía Wikipedia)
Para ayudar a cumplir con el CLS existe el atributo a nivel de ensamblado CLSCompliant, que hará que el compilador nos avise en tiempo de diseño con "Warnings" en aquellos puntos donde infringimos alguna regla del CLS. Este es uno de esos casos donde ... no cuesta tanto hacer las cosas bien :D
Algunas de las reglas del CLS son:
- Los elementos públicos no pueden diferenciarse unos de otros por las mayúsculas/minúsculas.
- No se pueden usar tipos sin signo (ie: UInt16, UInt43, ..etc...).
- Las sobrecargas de métodos no pueden diferenciarse por parámetros pasados por 'ref' ó 'out'.
- Los elementos públicos no pueden comenzar con un guión bajo (underscore).
Todas las reglas no afectan a elementos privados, relamente lo que importa es cuidar la forma de la funcionalidad que se va a mostrar, no lo que hay por dentro.
Es uan verdadera pena que como indica el MSDN en la nota del atributo CLSCompliant... el compilador de "Visual Basic" no indique estas advertencias... una verdadera pena.
El compilador actual de Microsoft Visual Basic no genera intencionalmente una advertencia de compatibilidad con CLS, sin embargo, una futura versión del compilador emitirá el aviso.
Una muestra que espero que sea clarificadora:
using System;
using System.Collections.Generic;
using System.Text;
[assembly: CLSCompliant(true)]
namespace CLSCompliant
{
public class MiClase
{
// 1. Los nombres de elementos públicos no pueden
// diferenciarse únicamente en las mayúsculas/minúsculas
// pues algunos lenguajes son case-insensitive.
public void Metodo1(){}
public void metodo1(){}
// Warning: 'CLSCompliant.MiClase.metodo1()' differing only
// in case is not CLS-compliant
public int Propiedad1 { get { return 0; } }
public int propiedad1 { get { return 0; } }
// Warning: 'CLSCompliant.MiClase.propiedad1.get' differing
// only in case is not CLS-compliant
/* --------------------- */
// 2. No se pueden usar tipos "sin signo" como elementos
// públicos de una clase ó incluso una interfaz.
public uint Metodo2(){return default(UInt32);}
// Warning: Return type of 'CLSCompliant.MiClase.Metodo2()'
// is not CLS-compliant
public void Metodo2(uint parametro){}
// Warning: Argument type 'uint' is not CLS-compliant
/* --------------------- */
// 3. Las sobre cargas de los métodos, no pueden diferenciarse
// por parámetros 'ref' ó 'out'.
public void Metodo3(int parametro){}
public void Metodo3(ref int parametro){}
// Warning: Overloaded method 'CLSCompliant.MiClase.Metodo3(ref int)'
// differing only in ref or out, or in array rank,
// is not CLS-compliant
/* --------------------- */
// 4. Los elementos públicos no pueden comenzar con un
// guión bajo (underscore).
public void _Metodo5(){}
// Warining: Identifier 'CLSCompliant.MiClase._Metodo5()'
// is not CLS-compliant
}
}
Subscribir