Recomendaciones para soluciones de Visual Studio 2010 que contienen proyectos 'Any CPU' y 'x86'

Question

A menudo ocurre que una sola solución C contiene algunos proyectos que son específicos de x86 (generalmente teniendo dependencias nativas) y otros que son 'Any UPC'.

Hasta hace poco siempre me había pasado al administrador de configuración y me había asegurado de que la plataforma de solución fuera 'Cualquier CPU'. Esto no es un gran problema; requiere ajustes ocasionales like the ones mentioned here, pero en general no es tan malo.

Sin embargo, recientemente comencé a preguntarme si estos esfuerzos están mal orientados. Claramente voy en contra de la forma en que Visual Studio 2010 (y previamente Visual Studio 2008) está diseñado para manejar esto. "Mixed Platforms" es en realidad una descripción precisa, y aunque inicialmente parece que hay algo mal, al pensarlo más, tengo que concluir que no es más incorrecto que "Any CPU".

Por lo tanto, últimamente he estado tratando de elegir entre mantener "Plataformas mixtas" o cambiar a "x86" como mi Plataforma de soluciones en tales casos. Esto último refleja la intención: el archivo EXE final es x86 y se ejecuta en modo de 32 bits en sistemas operativos de 64 bits. El primero sin embargo es lo que Visual Studio realmente quiere que sea.

En su experiencia, ¿hay alguna plataforma de solución particular que sea más adecuada de alguna manera que otras en esta situación?

Nota 1: en todos los casos que he encontrado, 'x 86' se justifica por las dependencias nativas y 'Cualquier CPU' se justifica por ser una biblioteca externa que es realmente independiente de la plataforma.

Nota 2: si he entendido bien, la solución plataforma no hace mucha diferencia; es solo un nombre Parece que cambia el estado predeterminado de la casilla de verificación "to-build-or-to-build" cuando se agregan nuevos proyectos, pero ese es el único efecto que tiene. ¿Derecha?

Answer 1

Habiendo tenido un poco más de experiencia con esto, esto es lo que ahora pienso:

• no hace ninguna diferencia en absoluto lo que la plataforma de solución se llama para un proyecto de plataforma mixta. El comportamiento de VS es exactamente el mismo, ya que requiere la misma cantidad de limpieza después de agregar un proyecto.
• "Plataformas mixtas" es un poco más preciso, por lo que tengo una ligera preferencia por esta.

Cambiar todo para x86 no es deseable por dos razones:

• Some algorithms are almost twice as fast in x64 mode.
• Cualquier biblioteca compartida que sea x86 no se puede usar en un proyecto que beneficia mucho del modo x64.
• Mantener las bibliotecas compartidas en dos plataformas, x86 + x64, es mucho más esfuerzo que mantenerlas "Cualquier CPU" y limpiar después de Visual Studio cada vez que rocía configuraciones de solución no deseadas en una solución.

Answer 2

Anuncio Nota 2: Sí. La plataforma de soluciones es solo un nombre para el conjunto de configuraciones de proyectos, incluido si se compila o no un proyecto en particular.

Personalmente utilizo x86 en todas las aplicaciones de escritorio (de escritorio porque se implementan en máquinas de usuarios finales sobre las que generalmente tiene poco control; esto es mucho más fácil si está implementando una aplicación de servidor en un servidor conocido).

Razones:

1. x 86 permite una depuración más sencilla - editar y continuar no se admite cuando se ejecuta en modo de 64 bits.
2. Nunca se puede anticipar cuándo en el futuro agregará una referencia a un ensamblado que requiera x86 y olvide probar correctamente en 64 bits, produciendo embarazosos errores de tiempo de ejecución en las implementaciones de 64 bits.

Answer 3

Solo configuré mi aplicación Windows Forms de inicio como "x86" y todas las bibliotecas de clase en el proyecto como AnyCPU. Si ejecuto la aplicación, todas las dependencias no administradas, incluso las de las bibliotecas de clase que son x86, todavía funcionan.

Ahora, si agrego una biblioteca de clases que no tiene dependencias x86 de mi proyecto a otra aplicación que está configurada como AnyCPU, funciona de fábrica.

Antes de hacerlo todas mis bibliotecas donde x86 y yo recibimos una excepción si quería usarlas en un proyecto de 64 bits.

Desde mi punto de vista, esa es la mejor solución.

Answer 4

Sí, esto entra en un lío al permitir que el convertidor de proyecto VS2010 importe un proyecto de una versión anterior. Quién no. Los IDE antiguos usaban Debug | Any CPU y Release | Any CPU como los nombres de configuración predeterminados. VS2010 realmente prefiere configurar Target Platform a x86 porque el IDE funciona mucho mejor cuando lo hace. Y usa Debug | x86 y Release | x86 como los nombres de configuración predeterminados.

Que produce la mezcla al importar un proyecto anterior. Y un extra conjunto de configuraciones (plataformas mixtas) que no pidió para hacer frente al desastre. Yuck. Tampoco puede eliminarlos, el botón Eliminar está deshabilitado en Configuration Manager.

Estos son solo nombres por cierto que no son realmente representativos de la configuración de Target de plataforma. Puede cambiar la configuración, no cambia mágicamente el nombre de la configuración. Yuck.

No se puede arreglar esto en el IDE. Tendría que editar los archivos .sln y .vcproj para deshacerse de las configuraciones adicionales y editar los nombres de las que desea conservar. O simplemente mantenga "Plataformas mixtas" como su configuración predeterminada e ignore el resto. Simplemente configure el objetivo de la plataforma para lo que necesita, no tiene que coincidir con el nombre de la configuración.