Ediciones ENI Editorial | líder en informática
Framework .NET y .NET Core
Introducción a .NET
Le venimos diciendo desde el comienzo de este libro que PowerShell obtiene su potencia del Framework .NET. Por fin ha llegado el momento de entrar en detalle.
Para hacerlo sencillo, cuando Jeffrey Snover diseñó PowerShell, el Framework .NET acababa de nacer y su popularidad aumentaba entre la comunidad de desarrolladores. En efecto, este framework ofrece un gran número de funciones listas para su uso, que permiten aumentar significativamente la productividad de los desarrolladores. Estas funciones, listas para su uso - llamadas «clases», en la jerga - evitan al desarrollador tener que reinventar la rueda, de modo que pueden centrarse en el código útil de su programa.
Snover sucumbió a los cantos de sirena del Framework .NET, para nuestro bien, y no nos quejamos por ello, ¡al contrario!
De modo que, cuando utilizamos PowerShell, estamos utilizando de manera indirecta el Framework .NET. Por ejemplo, cuando declaramos una variable, esta usa un tipo del Framework .NET y no un tipo específico de PowerShell (si bien pueden existir algunos).
En ocasiones, cuando PowerShell no posee el comando que deseamos, podemos invocar directamente ciertas clases del Framework .NET para alcanzar nuestro fin. Por ejemplo, veremos al final del capítulo cómo comprimir archivos en formato ZIP. En efecto, no hemos esperado a la versión 5 de PowerShell para crear archivos comprimidos...
El framework .NET
Conocido por muchos desarrolladores, el framework .NET es un componente de Windows que apareció en su versión final en 2002. Indispensable para la instalación de PowerShell, el framework está ahora instalado de forma nativa en los sistemas Windows. Destinado a facilitar el desarrollo de aplicaciones informáticas, el framework proporciona una inmensa biblioteca de clases sobre la cual se apoyan ciertos lenguajes como C#, VB.NET, J#, y por supuesto PowerShell.
Arquitectura software
Composición del Framework .NET
Sin entrar en detalles muy técnicos que no resultan realmente útiles para la comprensión, acuérdese simplemente de que el Framework .NET está compuesto por dos elementos principales:
-
La CLR (Common Language Runtime), entorno de ejecución compatible con todos los lenguajes de programación que respetan la CLS (Common Language Specification). CLR es el equivalente a la máquina virtual de Java; es quien interpreta el bytecode resultado de la compilación de un programa .NET.
-
Las bibliotecas de clases contienen todos los tipos que podemos encontrar en el Framework .NET. Cada clase se encuentra catalogada en un espacio de nombres.
Sucesivas versiones del Framework .NET
Con el paso de los años, el Framework .NET ha mejorado y tomado la dirección correcta. Las siguientes figuras muestran las nuevas API que han enriquecido el Framework...
.NET Core
A diferencia del Framework .NET, que solo funciona sobre la plataforma Windows, .NET Core ha nacido multiplataforma.
.NET Core es la última versión del Framework .NET, aunque es open source. Sí, ha leído bien. .NET Core es la reescritura completa del Framework .NET pero en versión open source. ¿Imagina el trabajo astronómico que ha hecho falta para pasar de una versión a otra? Es realmente colosal, pero no tenemos duda de que el objetivo se alcanzará en algunos años. Además, gracias a que .NET Core es open source, significa que todo el mundo puede contribuir en su desarrollo, lo cual no puede sino mejorar su portabilidad así como potenciar sus funcionalidades.
Esta portabilidad ha forzado a Microsoft a revisar su código y optimizarlo. Además, aunque .NET Core parte de una página en blanco, aprovecha más de quince años de experiencia adquirida por Microsoft durante el desarrollo de su hermano mayor. Con toda probabilidad, es por ello por lo que .NET Core es mucho más ligero y realmente más veloz que su hermano mayor.
La versión estable actual de .NET Core (en el momento de escribir estas líneas) es la versión 2.1.4.
¿Qué significa esto para nosotros, desarrolladores de scripts PowerShell?
En primer lugar, como comprenderá, estamos viviendo un periodo de cambio en el ciclo de vida de PowerShell....
PowerShell Core frente a Windows PowerShell, ¿cuál elegir?
Dejando las cosas claras, Microsoft dedica todo su esfuerzo y energía a .NET Core, así como a PowerShell Core. Si bien Windows PowerShell y el Framework .NET siguen teniendo soporte, evidentemente, estos dos componentes mayores del ecosistema Microsoft ya no evolucionarán más. No habrá nuevas funcionalidades, solamente parches de seguridad. Sí, es chocante, pero nos tenemos que hacer a la idea.
La versión 5.1 será, por tanto, la última versión de Windows PowerShell. El futuro está encaminado, por tanto, a buscar un mundo más abierto con PowerShell Core (versión 6). La transición puede llegar a ser dolorosa, ya que va a ser necesario probar todos nuestros scripts y, forzosamente, adaptar más de uno, pues supone un gran cambio. Dicho esto, todavía tenemos tiempo, pues PowerShell Core acaba de aparecer y Windows PowerShell va a contar con soporte todavía durante algunos años.
¿Qué versión de PowerShell escoger?
No tenemos otra opción que acompañar el cambio. Es la ley de la evolución, adaptarse o morir. Afortunadamente, este cambio no es tan dramático como parece, aunque sí ineludible. De modo que, desde nuestro punto de vista como autores y también como profesionales de la informática, le recomendamos...
Utilizar objetos .NET con PowerShell
A partir de ahora, y hasta el final del capítulo, no distinguiremos entre el Framework .NET y .NET Core, pues todo lo que vamos a ver a continuación se aplica a ambos frameworks.
En esta sección le explicaremos qué es el Framework .NET, qué contiene, cómo buscar las clases que nos pueden interesar, cómo crear objetos, y cómo enumerar sus miembros.
Hablaremos indistintamente de clase .NET o de tipo .NET, pues ambos términos hacen referencia a la misma cosa.
Antes que nada, sepa que, en el entorno .NET, todo tiene un tipo. Hasta ahora, sin realmente prestar atención, hemos manipulado numerosos objetos que poseían cada uno un tipo bien definido en la biblioteca del Framework. Tomemos por ejemplo el caso del objeto devuelto por el comando Get-Date.
PS > $Date = Get-Date
PS > $Date.GetType()
IsPublic IsSerial Name BaseType
-------- -------- ---- --------
True True DateTime System.ValueType Aplicando el método GetType del objeto representado por $Date, podemos ver que el tipo es DateTime y que su espacio de nombres es System. Por lo tanto el nombre completo es: System.DateTime.
Llamamos espacio de nombres (o namespace en inglés) a lo que precede al nombre de una o varias clases .NET o WMI. Se utilizan con el objetivo de organizar los objetos y así evitar confundir clases que podrían eventualmente poseer el mismo nombre.
Para obtener más información, sepa que todos los tipos (se trate de clases, estructuras, enumeraciones, delegados o interfaces) definidos en la bibliotecas de clase del Framework están detallados en el sitio web de Microsoft MSDN.
Descripción de una clase del Framework .NET en MSDN
Al igual que los tipos encontrados hasta ahora, cada tipo .NET que utilice posee uno o varios miembros que se pueden obtener mediante el comando Get-Member. Para ver los métodos y propiedades del tipo DateTime, teclee simplemente:
PS > Get-Date | Get-Member
TypeName: System.DateTime
Name ...Sacar partido de la potencia de .NET
El uso de .NET da a PowerShell una apertura sobre miles de clases listas para su uso. Por lo tanto, manipular objetos .NET equivale a permitir una gran flexibilidad pero también sirve para aportar otras perspectivas a nuestros scripts.
Para ilustrar este propósito vamos, en esta parte, a explicar paso a paso cómo sacar partido a algunas clases a través de diferentes escenarios como:
-
El Wake-on-LAN (despertar en remoto) de un equipo.
-
La compresión de archivos.
-
La visualización de tooltips.
1. Wake-on-LAN
El Wake-on-LAN (WOL) es un proceso que permite encender un equipo apagado desde la red Ethernet con una serie de bytes un poco particulares llamados «paquete mágico».
Hoy en día todas las placas base lo soportan, sin embargo puede ser que el Wake-on-LAN esté desactivado en la BIOS de su máquina.
El paquete mágico que permite lanzar el WOL es una sucesión de 102 bytes cuyos 6 primeros toman el valor hexadecimal FF y los 96 siguientes son 16 veces la repetición de la dirección MAC (Media Access Control) de la tarjeta de red del ordenador remoto. Para crear este paquete, usaremos la tabla de bytes siguiente:
PS > [byte[]]$Direccion_Mac = 0x00, 0x11, 0x43, 0x0E, 0x97, 0x4F
PS > [byte[]]$paquete = 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF
PS > $paquete += $Direccion_Mac * 16 Una vez constituido el paquete, tenemos que enviarlo por la red. Y para ello, utilizaremos la clase UdpClient (presente en el espacio de nombres System.Net.Sockets) que proporciona los servicios de red necesarios para enviar el datagrama UDP (User Datagram Protocol):
PS > $UdpClient = New-Object System.Net.Sockets.UdpClient Es gracias a esta clase y en particular al método Connect como podremos establecer una conexión con un host remoto. Bastará, a continuación, con una simple llamada al método Send para finalizar el envío del datagrama:
PS > $UdpClient.Connect(([System.Net.IPAddress]::Broadcast),1600)
PS > $UdpClient.Send($Paquete,$Paquete.Length)...