2011-09-15 9 views
6

Mi socio comercial y yo desarrollamos conjuntamente una aplicación web implementada en Azure. Mi cuadro está basado en Windows 7 de 64 bits, pero mi compañero está usando Windows 7 de 32 bits.Cómo implementar una versión de DLL de 64 bits en Azure, pero use la versión de 32 bits en los cuadros dev

Desde el IDE de VS2010 cuando he añadido una referencia a 'ieframe.dll' de mi directorio System32 (64 bits en mi caja), el IDE realidad traído la versión SysWoW64 (32 bits) de la DLL.

Ambas cajas dev funcionan a la perfección con la versión de 32 bits de WOW 'ieframe.dll', pero cuando hacemos uso de Azure que van a obtener un EntryPointNotFoundException al realizar una llamada/DllImport interoperabilidad en 'IEFrame. dll '. Parece que Azure quiere tener la versión de 64 bits.

¿Cómo podemos implementar la versión de 64 bits en Azure pero seguir usando la versión de 32 bits en nuestros cuadros de desarrollo?

EDITAR: Obviamente, podemos hacer esto manualmente copiando 'ieframe.dll' de 64 bits en algún lugar y luego colocarlo manualmente en el directorio 'bin', pero ¿hay alguna forma mejor de practicar esto en Azure? ?

EDIT # 2: Para este escenario, terminamos cambiando el nodo para Azure de osFamily = "1" a osFamily = "2". Al hacer esto, se instala Windows Server 2008 R2 que incluye IE8 (en lugar de IE7 en Windows Server 2008 SP1). No hay necesidad de meterse con las versiones de 32 contra 64 bits o copiar manualmente las DLL hasta el servidor.

Respuesta

5

Si siempre está implementando en Azure desde una máquina de 64 bits, puede modificar el archivo de proyecto para copiar la DLL correcta a la carpeta bin en tiempo de compilación según el tipo de procesador de la máquina que realiza la compilación. Esto funciona muy bien para nosotros porque nos desplegamos en Azure desde un servidor de compilación de 64 bits. Si esto suena como una buena solución, siga estos pasos:

1 - Crear una carpeta de la liberación externa que contiene dos subcarpetas denominadas 32 y 64.
2 - Colocar la versión de 32 bits de la DLL en la carpeta 32 y la versión de 64 bits en la carpeta 64.
3 - Abra el archivo del proyecto ofensivo en un editor de texto.
4 - Agregue el siguiente nodo al archivo de proyecto justo después del ItemGroup que contiene los elementos de "referencia incluida". Esto copiará el archivo DLL correcta en función de las variables de entorno del sistema suministrado:

<ItemGroup> 
    <DllToCopy Condition=" '$(PROCESSOR_ARCHITECTURE)' == 'x86' And '$(PROCESSOR_ARCHITEW6432)' == '' " Include="..\ext-lib\32\mydll.dll" /> 
    <DllToCopy Condition=" '$(PROCESSOR_ARCHITECTURE)' == 'AMD64' Or '$(PROCESSOR_ARCHITEW6432)' == 'AMD64' " Include="..\ext-lib\64\mydll.dll" /> 
</ItemGroup> 

5 - Por último, alterar objetivo BeforeBuild del proyecto, así:

<Target Name="BeforeBuild"> 
    <Copy SourceFiles="@(DllToCopy)" DestinationFolder="$(OutputPath)" /> 
</Target> 

Otra opción sería copiar la DLL correcta a la carpeta bin basada en una configuración de compilación (menos ideal). Por ejemplo, si has tenido una configuración de construcción Producción nombre que le sigue los pasos anteriores, excepto el paso 4 contendría lo siguiente:

<ItemGroup> 
    <DllToCopy Condition=" '$(Configuration)' != 'Production' " Include="..\ext-lib\32\mydll.dll" /> 
    <DllToCopy Condition=" '$(Configuration)' == 'Production' Include="..\ext-lib\64\mydll.dll" /> 
</ItemGroup> 

Sin embargo, otro (e incluso menos ideal) opción sería copiar el de 64 bits versión de la DLL a la carpeta bin utilizando una tarea de inicio de Azure.

Espero que esto ayude.

+0

Gracias por su detallada respuesta. Mi cofundador y yo consideramos todos los comentarios que nos brindó.Al final, mordió la bala y decidió actualizar a una máquina de 64 bits con un sistema operativo de 64 bits para que él, yo y Azure todos usemos la misma arquitectura de 64 bits. Anteriormente, estaba implementando todos los nuevos bits en Azure desde su caja de 32 bits. Esto funcionó bien hasta que nos encontramos con el problema que anoté anteriormente con la dependencia ieframe.dll. ¡Odiamos tener que admitir configuraciones múltiples, así que era hora de "Man Up" para una nueva caja! –

+0

Dicho sea de paso: el uso de una tarea de inicio de Azure fue la solución más frecuentemente sugerida para nuestro dilema, pero como notó, de todas las "correcciones" fue la más fea. Una vez más, apreciamos sus comentarios. Es bueno saber cómo hacer esto si, por alguna razón, tenemos otro desarrollador a bordo que está casado con una máquina de desarrollo de 32 bits. –

+0

Vea Edición # 2 más arriba para la solución que finalmente terminamos usando. –

Cuestiones relacionadas