Modificaciones en el compilador
Control de la versión del lenguaje
A partir de la versión 2.0 del .NET Framework, el compilador de C# proporciona una nueva opción /langversion que permite restringirle las características del lenguaje que se permitirán usar durante la compilación para solo permitir las de una cierta versión o estándar del lenguaje. Por ahora, los valores que esta opción admite son los siguientes:
|
Valor |
Descripción |
|
default |
Utilizar las características de la versión más actual del lenguaje para la que el compilador se haya preparado. Es lo que se toma por defecto |
|
ISO-1 |
Usar las características de la versión 1.X del lenguaje estandarizada por ISO. Por lo tanto, no se permitirá el uso de genéricos, métodos anónimos, etc.[17] |
Tabla 21: Identificadores de versiones del lenguaje
Por ejemplo, dado el siguiente fichero version2.cs que usa tipos parciales:
partial class Version2
{
static void Main()
{
}
}
|
Si lo intentamos compilar como sigue:
| csc version2.cs /langversion:iso-1 |
Obtendremos un mensaje de error indicándonos que el uso de tipos parciales no está permitido en la versión 1.X estándar de C#:
| Version2.cs(1,1): error CS1644: Feature 'partial types' cannot be used because it is not part of the standardized ISO C# language specification |
Control de la plataforma de destino
Dado que a partir de la versión 2.0 de Microsoft.NET se soportan las arquitecturas de 64 bits de Intel y AMD, el compilador de C# admite una nueva opción /platform por medio de la que se le puede indicar el tipo de plataforma hacia la que se desea dirigir el código que se compila. Los valores que admite son los siguientes:
|
Valor |
Significado |
|
Anycpu |
Compilar para cualquier plataforma. Es lo que por defecto se toma |
|
X86 |
Compilar para los procesadores de 32 bits compatibles con Intel |
|
X64 |
Compilar para los procesadores de 64 bits compatibles con AMD |
|
Itanium |
Compilar para los procesadores de 64 bits Intel Itanium |
Tabla 22: Identificadores de plataforma de destino
Gracias a esta opción, si el código se dirige hacia una plataforma de 64 bits y se intenta ejecutar bajo una plataforma de 32 bits saltará un mensaje de error como el siguiente:
Por el contrario, si se dirige a plataformas de 32 bits y se intenta ejecutar en una de 64 bits, automáticamente Windows simulará la ejecución del mismo en un entorno de 32 bits a través de su funcionalidad WOW (Windows On Windows)
Aunque en principio lo ideal es realizar el código lo más independiente posible de la plataforma, se da esta opción porque cuando se opera con código inseguro se pueden tener que realizar suposiciones sobre las características concretas de la plataforma hacia la que se dirige el código, fundamentalmente en lo que respecta al tamaño ocupado en memoria por ciertos tipos de datos que se manipulen mediante aritmética de punteros.
Envío automático de errores a Microsoft
A partir de .NET 2.0, el compilador de C# da la opción de enviar automáticamente a Microsoft los errores internos del mismo que durante su uso pudiesen surgir para así facilitar su detección y corrección a Microsoft (errores de csc.exe y no del código que se pretenda compilar) Por ejemplo, si se intenta compilar el siguiente código con el compilador de C# 2.0 de la Beta 1 del Microsoft.NET Framework SDK 2.0:
using System;
using System.Collections;
class Error
{
IEnumerator GetEnumerator()
{
try {}
catch { yield break; }
finally {}
}
static void Main()
{}
} |
El compilador sufrirá un error interno que impedirá finalizar el proceso de compilación:
|
error CS0583: Internal Compiler Error (0xc0000005 at address 56D1EEC4): likely culprit is 'TRANSFORM'.
An internal error has occurred in the compiler. To work around this problem, try simplifying or changing the program near the locations listed below. Locations at the top of the list are closer to the point at which the internal error occurred.
error.cs(6,14): error CS0584: Internal Compiler Error: stage 'TRANSFORM' symbol 'Error.GetEnumerator()'
error.cs(6,14): error CS0584: Internal Compiler Error: stage 'BIND' symbol 'Error.GetEnumerator()'
error.cs(6,14): error CS0584: Internal Compiler Error: stage 'COMPILE' symbol 'Error.GetEnumerator()'
error.cs(6,14): error CS0584: Internal Compiler Error: stage 'COMPILE' symbol 'Error.GetEnumerator()'
error.cs(6,14): error CS0584: Internal Compiler Error: stage 'COMPILE' symbol 'Error.GetEnumerator()'
error.cs(4,7): error CS0584: Internal Compiler Error: stage 'COMPILE' symbol 'Error'
error.cs(114297930,1): error CS0584: Internal Compiler Error: stage 'COMPILE' symbol '<global namespace>'
error.cs: error CS0586: Internal Compiler Error: stage 'COMPILE'
error CS0587: Internal Compiler Error: stage 'COMPILE'
error CS0587: Internal Compiler Error: stage 'BEGIN'
|
Para realizar el envío del error a Microsoft se puede usar la opción /errorreport del compilador, la cual admite los siguientes valores:
|
Valor |
Descripción |
|
None |
No enviar el error a Microsoft. Es lo que se hace por defecto. |
|
Prompt |
Preguntar si enviar el error. Esto hará que durante la compilación se muestre al usuario una ventana como la siguiente en la que se le pide permiso para la realización del envío y se le de la opción de inspeccionar la información que se enviará a Microsoft por si desea asegurarse de que no se vayan a enviar datos sensibles sobre el equipo o el código fuente compilado (puede que se les envíe parte del mismo para facilitarles la detección del error):
|
|
Send |
Enviar automáticamente la notificación a Microsoft, sin necesidad de tener que confirmarlo a través de la ventana que la opción anterior muestra. |
Tabla 23: Opciones para el envío de errores a Microsoft
Lo ideal es combinar esta opción con la opción /bugreport ya conocida, para que así el informe del error sea más rico y la detección de sus causas sea más sencilla. Como en este caso la información que se enviará a Microsoft es mayor y por consiguiente puede que se tarde mucho más enviársela a través de Internet (sobre todo si se usa un módem convencional para acceder a la Red), se informará antes al usuario de esta circunstancia y se le preguntará si está seguro de realizar el envío. Si confirma, aparecerá una ventana como la siguiente con información sobre el progreso del envío del informe de error:
Concretización de avisos a tratar como errores
La opción /warnaserror permite ahora que se le concreten los avisos que se desea que se traten como errores. Por ejemplo, para decirle que sólo considere como errores los avisos con código CS0028:
| csc test.cs /warnaserror:28 |
Así mismo, a VS.NET se le ha añadido la posibilidad de configurar los avisos a tratar como errores y los avisos a filtrar a través de la hoja de propiedades del proyecto. En concreto, desde sus controles Configuration Properties à Build à Treat Warnings as Errors y Configuration Properties à Build à Suppress specific warnings.
Visibilidad de los recursos
Las opciones /linkres y /res permiten ahora especificar la visibilidad de los recursos que se enlazarán o incrustarán en el ensamblado generado, de modo que se pueda configurar no permitir acceder a los mismos desde otros ensamblados. Para ello, tras el identificador del recurso se puede incluir una de estas partículas separada por una coma:
|
Valor |
Descripción |
|
public |
Podrá accederse a los recursos del ensamblado libremente desde cualquier otro ensamblado. Es lo que se toma por defecto |
|
private |
Sólo podrá accederse a los recursos desde el propio ensamblado |
Tabla 24: Indicadores de visibilidad de recursos
Por ejemplo:
| csc test.cs /linkres:misrecursos.resources,recursos.cs,private |
Firma de ensamblados
El compilador de C# 2.0 incorpora opciones relacionadas con la firma de ensamblados que hasta ahora venían siendo proporcionada de manera externa al mismo, pues como al fin y al cabo compilar un ensamblado con firma o sin ella no es más que una opción de compilación, la forma más lógica de indicarlo es a través de opciones del compilador.
Para poder instalar un ensamblado en el GAC es necesario que tenga un nombre seguro; es decir, que esté firmado. Este proceso de firma consiste en utilizar una clave privada para cifrar con ella el resultado de aplicar un algoritmo de hashing al contenido del ensamblado, e incluir en su manifiesto la clave pública con la que luego poder descifrar la firma y comprobar que el ensamblado no se ha alterado y procede de quien se espera.
Para generar la pareja de claves pública-privada se puede utilizar la herramienta sn.exe (singing tool) del SDK, que se puede usar como sigue para generar aleatoriamente un par de claves y guardarlas en un fichero (por convenio se le suele dar extensión .snk):
Luego, la firma del ensamblado se realizará especificando durante la compilación la ruta del fichero en el que se almacenan las claves a utilizar para realizar la firma a través de la nueva opción /keyfile incluida en el compilador de C# 2.0 para estos menesteres:
| csc test.cs /keyfile:misClaves.snk |
En lugar de especificar las claves como fichero, también es posible instalarlas en un contenedor público y referenciar al mismo durante la compilación. Para instalarlas en el contenedor se usa de nuevo la herramienta sn.exe, indicándole ahora la opción –i seguida de la ruta del fichero y el nombre del contenedor donde instalarla. Por ejemplo:
| sn –i misClaves.snk contenedorJosan |
Y al compilar se referenciaría al contenedor con la opción /keycontainer de csc:
| csc test.cs /keyname:contenedorJosan |
El uso de las opciones /keyfile y /keycontainer son ahora la práctica recomendada por Microsoft para la firma de los ensamblados, en detrimento de los antiguos atributos de ensamblado AssemblyKeyFile y AssemblyKeyName que antes se usaban para estas labores. De hecho, si se insiste en seguir utilizándolos el compilador emitirá mensajes de aviso informando de la inconveniencia de hacerlo. Lógicamente, en los ensamblados generados utilizando estas opciones ya no estarán presentes dichos atributos.
Las opciones /keyfile y /keycontainer se pueden combinar con /delaysign para conseguir que el proceso de firma no se haga al completo, sino que en vez de calcularse y guardarse la firma del ensamblado entre sus metadatos sólo se reserve en los mismos el espacio necesario para posteriormente incluírsela y se les añada la clave pública con la que se podrán instalar en el GAC para realizarles pruebas. A esto se le conoce como firma parcial, y para posteriormente realizar la firma completa al ensamblado se puede utilizar la utilidad sn.exe para refirmarlo, ya sea en base a un fichero de claves o a un contenedor público tal y como a continuación se muestra con los siguientes ejemplos:
|
sn.exe –R test.dll misClaves.snk
sn.exe –Rc test.dll contenedorJosan |
Nuevamente, en .NET 1.X la firma retrasada de los ensamblados se realizaba a través de un atributo de ensamblado (AssemblyDelaySign), cosa que ahora no se recomienda y que provocará la aparición de mensajes de aviso durante la compilación si se utiliza.