Estoy usando PowerShell 5.1, Windows 10 x64.
¿Cuál de estos 2 cmdlets debo usar para cargar ensamblajes .NET (en particular, ensamblajes .NET Framework 4+) en PowerShell? ¿Cuál es la diferencia central entre ellos? Quiero cargar ensamblajes para acceder a tipos, crear objetos, llamar a métodos, etc.
No he encontrado declaraciones explícitas en la documentación. Estos cmdlets se describen como si fueran cosas completamente diferentes. La documentación de MSDN para Import-Module ni siquiera contiene ejemplos para la carga de ensamblajes .dll , solo módulos de PowerShell. Sin embargo Import-Module funciona con ensamblajes de .NET Framework (sin embargo, solo .dll ): puedo trabajar perfectamente con tipos de ensamblajes importados, sus ensamblajes a los que se hace referencia también se resuelven y cargan. ¿Porqué es eso?
En otras palabras, según mi experiencia, aún no he encontrado ninguna diferencia entre estos 2 métodos de importación de ensamblajes (al menos para los ensamblajes .NET Framework 4 .dll ).
Esta antigua publicación de blog: Uso de ensamblajes de .NET Framework en Windows PowerShell incluso usa Reflection.Assembly.LoadWithPartialName . Creo que esto se debe a que cargan un ensamblado desde el GAC y no quieren especificar la ruta completa (aunque puedo estar equivocado).
Para mis ensamblajes, conozco la ruta completa a ellos, por lo que puedo especificarlo tanto en Import-Module como Add-Type . Nuevamente, ¿cuál es la diferencia y qué debo usar?
¡Gracias!
Powershell tiene tres formas principales de importar clases, sin contar los métodos .net como reflection.assembly . En general, todos ellos harán bien lo que necesitas, pero tienen características adicionales:
tiene, con mucho, la mayor flexibilidad y puede importar módulos básicos (generalmente archivos .psd1 o .psm1) y sus ensamblajes necesarios, módulos CIM (con archivos CDXML), objetos de tipo [Assembly] , ensamblajes a través de archivos .dll, cmdlets a través de . dll, y probablemente más. Hay más funciones para importar módulos PS, pero no para clases que no sean "cargar todo" .
tiene un montón de funcionalidad adicional para agregar clases de manera eficiente si lo necesita. Por ejemplo, puede tomar definiciones de tipo C#/VB/JScript como cadenas y cargarlas directamente. Personalmente, solo lo uso cuando lo necesito, o si import-module no puede importar correctamente un archivo dll, pero hay muchas más funciones enumeradas en la ayuda. No importa módulos como las otras opciones.
Relativamente nuevo y solo en v5.1+. Importará definiciones de clase desde un módulo, a diferencia Import-Module o la instrucción #requires . De lo contrario, se comporta de manera muy similar a ipmo , pero me gusta por su legibilidad y prefiero using namespace a la versión .net:
using module ModuleName # or using assembly 'C:\path\to\assembly.name.subassembly.whatever.dll' using namespace assembly.name.subassembly.whatever.additional.namespace [NiceAndShort]::Foosus ensamblajes a los que se hace referencia también se resuelven y cargan. ¿Porqué es eso?
Desafortunadamente, powershell toma el camino de simplemente cargar cada ensamblado (y sus dependencias, y las propias dependencias de powershell) en el mismo contexto. Esto puede causar algunos dolores de cabeza cuando se trata de versiones de dependencia en conflicto. Se explica mejor en Resolver conflictos de dependencia de ensamblado de módulos de PowerShell .