Soporte para código no administrado en .NET Framework

La plataforma .NET es actualmente el entorno de desarrollo para aplicaciones administrativas y de redes más popular y avanzado existente para Windows y, mediante el uso de Mono Framework, Linux y otros sistemas operativos.

El rápido crecimiento de .NET es explicable, principalmente, por razones de mercado. Sin duda que el impulso de una corporación dominante como Microsoft (y, en menor medida, de Novell al apoyar el desarrollo de Mono) no es algo que deba ignorarse en este análisis, pero, más allá de estas consideraciones, hay otros fundamentos que hacen a .NET merecedor de esta progresiva hegemonía:

 

• Fue diseñado desde el comienzo como un entorno independiente del lenguaje de programación. A diferencia de Java, sobre .NET se pueden encarar desarrollos en distintos lenguajes (C# y VB .NET son los mas populares), incluso en un mismo proyecto. Por ejemplo, mientras unos programadores pueden desarrollar la interface de usuario usando VB .NET, otros pueden abocarse a la lógica de negocio creando una librería en C# o Delphi.NET.
• Cuenta con una Biblioteca de Clases (BCL) robusta, muy completa y con una organización interna coherente, facilitando de así el desarrollo.
• El código compilado es, al igual que Java, independiente de plataforma (ByteCode). Gran parte de los ensamblados generados con .NET para Windows pueden ejecutarse, sin necesidad de recompilar, sobre Linux mediante Mono.
• Otra característica que lo hace similar a Java es la facilidad en la depuración y la capacidad del compilador en tiempo real (JIT) de detectar errores no encontrados en la fase de compilación. También se puede ajustar la seguridad del ensamblado final, haciendo que este solo funcione en un entorno apto y con los privilegios adecuados.
• Por ultimo, .NET supera a Java (plataforma en la que se inspira) al brindar un mecanismo de cache de ensamblados (ya compilados en código de maquina) y a la capacidad de sobrepasar los chequeos de seguridad mencionados anteriormente usando los servicios que brinda el sistema operativo en forma directa.

Entonces, un programa en .NET desarrollado en un lenguaje que soporte esta funcionalidad (C#, por ejemplo) puede acceder a direcciones de memoria (Punteros) sin intermediarios trabajando igual que el código compilado en lenguajes clásicos como C o C++.

El uso de esta característica de .NET, llamada código no administrado, no es algo que sea necesario ni recomendable para el desarrollo de aplicaciones habituales de tipo administrativo o gestión tal como se advierte en la documentación oficial de MSDN:

"Para mantener la seguridad de tipos y la seguridad, C# de manera predeterminada no admite la aritmética con punteros. Sin embargo, utilizando la palabra clave unsafe, es posible definir un contexto no seguro en el que se pueden utilizar punteros…

En el Common Language Runtime (CLR), se hace referencia al código no seguro como código no comprobable. El código no seguro en C# no es necesariamente peligroso; simplemente es código cuya seguridad no puede ser comprobada por el CLR. Por consiguiente, el CLR sólo ejecutará código no seguro si se encuentra en un ensamblado de plena confianza. Si utiliza el código no seguro, es su responsabilidad garantizar que su código no introduce riesgos de seguridad o errores de puntero."

Entonces, ¿En que situaciones es conveniente (o incluso necesario) usar Código no administrado?
 

• Cuando se trabaja con grandes volúmenes de datos frecuentemente, donde el código administrado puede afectar negativamente el rendimiento global de la aplicación. Esto puede ocurrir, por ejemplo, en rutinas de compresión / descompresión, de codificación / decodificación, de generación / verificación de checksums, algoritmos de ordenamiento complejos, etc.
• Cuando el tiempo de respuesta de la aplicación y la interacción con el usuario es critico. Por ejemplo, cuando se usan rutinas de Video o 3D.
• Cuando se debe interactuar directamente con el hardware o utilizar funciones y librerías del sistema operativo (API).
• Cuando se desea economizar al máximo el uso de memoria de la aplicación y evitar copias de memoria redundantes.

Sintetizando, programando con punteros podemos aproximarnos a la economía, flexibilidad y potencia que nos brindan los compiladores clásicos como C / C++ pero usando nuestro lenguaje preferido y sin salirnos de .NET; aunque, como contrapartida, también nos aproximamos a los riesgos que justamente trae aparejado el uso de estos compiladores.

Es por estos riesgos que no todos los lenguajes soportan el código no administrado y por lo cual, para mantener una interface común y equitativa a todos los lenguajes, la BCL no brinda al programador facilidades para su uso.

Entonces, las dificultades para el programador se multiplican dado que además de prestar la atención extra que requiere el desarrollo de este código, también debe trabajar doblemente para desarrollar y depurar rutinas básicas como copiar memoria, ordenar, crear colecciones, etc. Es por eso, que esta característica diferenciadora de Java y extensamente utilizada por Microsoft al desarrollar internamente la BCL, es muy poco usada por los programadores que desarrollan sus proyectos de .NET.

Pointers.NET es un proyecto de código abierto bajo licencia GPL.

Su principal ensamblado (enpalermo.dll) es una extensa librería (de casi 100.000 líneas de código) que brinda este apoyo en las clases y funciones básicas que el programador requiere para poder abocarse exclusivamente al desarrollo de sus propias rutinas.