c# - rutas - Recomendaciones para las soluciones de Visual Studio 2010 que contienen proyectos ''Cualquier CPU'' y ''x86''

rutas de acceso de referencia visual studio

Question

A menudo sucede que una única solución de C # contiene algunos proyectos que son específicos de x86 (generalmente por tener dependencias nativas) y otros que son ''Cualquier CPU''.

Hasta hace poco, siempre había accedido al administrador de configuración y me había asegurado de que la plataforma de la solución fuera ''Cualquier CPU''. Esto no es demasiado problema; requiere ajustes ocasionales como los mencionados aquí , pero en general no es tan malo.

Sin embargo, recientemente comencé a preguntarme si estos esfuerzos son erróneos. Claramente, estoy yendo en contra de la forma en que Visual Studio 2010 (y anteriormente Visual Studio 2008) está diseñado para manejar esto. "Plataformas mixtas" 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 "Cualquier CPU".

Entonces, últimamente he estado tratando de elegir entre mantener "Plataformas mixtas" o cambiar a "x86" como mi Plataforma de soluciones en tales casos. Este ú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. Lo primero, sin embargo, es lo que Visual Studio realmente quiere que sea.

Según su experiencia, ¿existe una plataforma de solución particular que sea más adecuada de alguna manera que las otras en esta situación?

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

Nota 2 : si entiendo correctamente, la plataforma de soluciones no hace mucha diferencia; es solo un nombre Parece que cambia el estado predeterminado de la casilla de verificación "construir o no construir" cuando se agregan nuevos proyectos, pero ese es el único efecto que tiene. ¿Derecha?

Answer 1

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

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

Cambiar todo a x86 es indeseable por dos razones:

• Algunos algoritmos son casi el doble de rápidos en el modo x64 .
• Cualquier biblioteca compartida que sea x86 no se puede usar en un proyecto que se beneficia mucho del modo x64.
• Mantener las bibliotecas compartidas en dos plataformas, x86 + x64, es mucho más esfuerzo que mantenerlas en "Cualquier CPU" y limpiar después de Visual Studio cada vez que agrega configuraciones de soluciones no deseadas a una solución.

Answer 2

Sí, esto es un poco complicado al permitir que el convertidor de proyectos VS2010 importe un proyecto de una versión anterior. Quien no Los IDE antiguos utilizaron Depurar | Cualquier CPU y Liberar | Cualquier CPU como los nombres de configuración predeterminados. VS2010 realmente prefiere establecer el objetivo de la plataforma en x86 porque el IDE funciona mucho mejor cuando lo haces. Y utiliza Debug | x86 y Release | x86 como los nombres de configuración predeterminados.

Lo que produce la mezcla al importar un proyecto antiguo. Y un conjunto adicional de configuraciones (plataformas mixtas) que no solicitó para lidiar con el desorden. Puaj Tampoco puede eliminarlos, el botón Eliminar está deshabilitado en el Administrador de configuración.

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

No puedes 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 los que desea conservar. O simplemente mantenga "Plataformas mixtas" como su configuración predeterminada e ignore el resto. Simplemente configure el objetivo de la plataforma según lo que necesite, no tiene que coincidir con el nombre de la configuración.

Answer 3

Solo he configurado mi aplicación de inicio de Windows Forms como "x86" y todas las bibliotecas de clases en el proyecto como AnyCPU. Si ejecuto la aplicación, todas las dependencias no administradas, incluso de las bibliotecas de clases 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 manera inmediata.

Antes de eso hice todas mis bibliotecas donde x86 y obtuve 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

Nota de anuncio 2 : sí. La plataforma de soluciones es solo un nombre para el conjunto de configuraciones del proyecto, incluido si se debe construir o no un proyecto en particular.

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

Razones:

1. x86 permite una depuración más fácil: editar y continuar no se admite cuando se ejecuta en modo de 64 bits.
2. Nunca puede anticipar cuándo, en el futuro, agregará una referencia a un ensamblaje que requiera x86 y olvide realizar las pruebas correctamente en 64 bits, lo que producirá vergonzosos errores de ejecución en implementaciones de 64 bits.