Cómo gestionar el desarrollo de PowerShell con las versiones x86 y x64 ins complemento

Question

Actualmente estoy escribiendo un complemento PowerShell que tiene dependencias específicas en los ensambles de modo mixto (asambleas que contienen código nativo) que apuntan específicamente a x64 o x86. Tengo las dos versiones del ensamblado dependiente, pero me gustaría saber cuál es la mejor para gestionar la construcción y despliegue de este complemento, en concreto:

1. ¿Es necesario tener dos versiones del complemento, uno x86 y x64 uno, y el uso de las dos versiones diferentes de installutil para instalarlo, una vez para cada arquitectura?
2. Suponiendo # 1 es verdadera, es recomendable instalar las dos versiones diferentes del complemento en los diferentes "Archivos de programa" y "Archivos de programa (x86)" directorios?
3. ¿Cuál es el ideal (menor molestia) manera de estructurar un par de proyectos que comparten todo, pero una sola referencia, con el fin de construir para las dos arquitecturas diferentes?
4. Si el complemento se compila como "Cualquier CPU", y los DLL dependientes están ambos carga en el GAC, será la carga de tiempo de ejecución el montaje correcto de la GAC ??basado en la arquitectura de la actualmente en ejecución anfitrión PowerShell?
5. ¿Hay una manera mancha de forma dinámica, en tiempo de ejecución, elija la que depende DLL de carga (si no puede, por diversas razones, se instalará en la GAC) sin caer en dolores de cabeza con los contextos de carga asamblea?

Answer 1

Terminé la creación de un módulo (gracias, Richard!), Pero eso no solucionó los problemas relacionados con la arquitectura del procesador. Con el fin de resolver que, puse ambas versiones de la DLL dependiente en el directorio de módulos, y en el constructor de cada cmdlet pongo algún código de inicialización (que sólo se ejecuta una vez) para cargar la versión adecuada de la DLL dependiente.

Gracias, todos, para los punteros.

Answer 2

Marcos, tenemos esta misma situación con las extensiones de PowerShell de la Comunidad con las versiones de 32 bits y 64 bits de 7zip.dll. Puede muy fácil trabajar alrededor de esto PInvoking a LoadLibrary temprano en su arranque de complemento (o antes de tener que llamar a la DLL nativo). A continuación, puede probar si usted es un proceso de 32 bits o 64 bits (IntPtr.Size) y luego cargar manualmente el archivo DLL correcta mediante el LoadLibrary PInvoke. Después de que el, DllImport ( "YourNative.dll") se dará cuenta de que el DLL ya está cargado y el uso que DLL.

Tome un vistazo a estos dos archivos de código fuente PSCX: http://pscx.codeplex.com/SourceControl/changeset/ view / 74794? ProjectName = Pscx # 1358100 http://pscx.codeplex.com/SourceControl/changeset/ view / 74794? ProjectName = Pscx # 1358102