Últimamente me he encontrado con dudas y preguntas que se plantean algunos compañeros sobre la compilación en 64bits. En ocasiones, me he encontrado cosas un poco “liososas” al respecto, pero, sinceramente, despues de hacer un pequeño ejemplo para chequearlo, veo que no parece tan complicado, o al menos eso creo yo.
Veamos ese ejemplo “chorras” pero que una vez más nos da la solución a la duda
- Crear una solución Visual Studio “Basic Deploy x32 x64”
- Añadir un proyecto de tipo Consola
- Añadir otro proyecto de tipo “Setup” según se muestra en la siguiente figura:
- Ahora nuestra solución quedará de la siguiente manera:
- Lo siguiente es crear una nueva plataforma de compilación “x64” tal y como sigue:
- Hacer click sobre la solución y seleccionar “Configuration Manager…
-
- A continuación podemos eligir entre copiar la configuración de una plataforma ya existente o vacía (“<Empty>”). La ventaja de utilizar una existente (x86, que siempre está present), tenemos la ventaja de que las opciones de compilación para “Debug” y “Release” están listas.
- Ahora ya está todo listo, ajustamos la configuración; “Debug” y “Release” si no lo hemos hecho en el paso anterior, es decir en caso de haber creado la plataforma a partir de una vacía. Para ello tendremos que seleccionar en cada proyecto y para cada uno de los tipos de configuración si queremos marcar, “DEBUG”, “TRACE”, etc… Entre otras cosas, es posible que nos interese cambiar el “Output path”, sino, por defecto la compilación en 32 bits se realizará en “bindebug” y la de 64 en “binx64debug”.
- Si ejecutamos el proyecto en 32 bits y observamos el c podemos observar como las Dlls utilizadas; Sytem.Core, System.Data, etc son las de 32 bits.
- Sin embargo, si ejecutamos la aplicación en 64bits y volvermos a observar el “Process Exprorer”, vemos como las DLLs utilizadas son las de 64 bits.
Llegado este momento el proyecto compila y se ejecuta en 32 y 64 bits. Es en momento de ver como se comporta el proyecto de SETUP:
Entre las propieades del proyecto de setup tenemos la propiedad “TargetPlatform” que tendremos que cambiar según la compilación que queramos hacer; para 32 o para 64 bits.
Hasta aquí, el caso fácil y prácticamente todo automático, pero, siempre existen algunas excepciones o “complicaciones” a tener en cuenta:
- ¿Que pasa si tengo que trabajar con directorios específicos de 64bits; “ProgramFiles64Folder”, “CommonFiles64Folder” o, para el caso de 32 bits “ProgramFilesFolder”, “CommonFilesfolder”, etc.? En este caso sólo se podrá trabajar con una plataforma específica, y es posible que tengamos que crear dos proyectos de Setup, uno para 32 y otro para 64.
- Pero, ¿Y si tenemos mucha lógica en el setup; nuevos formularios, custom actions, etc? La idea es intentar evitar dependencias de cada plataforma. Desde mi punto de vista lo mejor es lanzar el .MSI desde un .BAT o .VBS pasando el parámetro “TARGETDIR”. En cuanto a otros directorios o depencias, lo mejor es trabajar con “custom actions” creando la lógica adecuada, pero de esta manera siempre un único Setup y sólo cambiando la propiead “TargetPlatform”. Para más detalle sobre todo esto, hechad un vistazo a mi anterior post; “Como hacer un setup en 15 min”.
- ¿Que ocurre si nuestro proyecto de 64 bits trabaja con DLLs concretas de terceros?¿Que ocurre con las referencias? Una buena idea puede ser; crear un nuevo proyecto vacío (sin ninguna clase) en el mismo directorio del proyecto de 32 bits, de manera que ambos proyectos lo compartan todo. Es decir, tendríamos en un mismo directorio dos ficheros “.csproj”. Bastará incluir las referencias por separado en cada uno de los proyectos y en algún caso, alguna directiva de compilación. En este caso nos tocará crear dos proyectos de Setup. ¡intentemos unificar toda la logica!.
Estos úiltimos puntos dependerán de la complejidad que tenga nuestro Setup. La cuestión es, complicarse cuanto menos, mejor. El principio KISS, siempre presente.
Saludos
Juanlu
Hola.
Ojito con en x64 y en AnyCPU del .NET. Si no lo han arreglado, suele funcionar “diferente” que el x86, no sólo con más problemas (bugs de la plataforma), sino también con comportamiento cambiado.
Aparte de que la depuración es más “peligrosa”: por ejemplo, si estás depurando un AnyCPU (en x64) desde Visual Sutudio, muchas excepciones no serán controladas porque se “pierden” en el salto entre x64 y x86 con el debugger y en debug no te enteras de ellas pero en casa del cliente sí.
Muchas gracias Rafael, lo tendré en cuenta e intentaré hacer alguna pruebecilla sobre este tema.
Ya te comentaré.
Saludos
Juanlu