2011-08-16 701 views
6

tengo una aplicación de .NET,conversión de aplicación .NET 32 bits a 64 bits

biblioteca Clase
  • (Plataforma de destino establecido en Cualquier CPU)
  • Aplicación Winform (Plataforma de destino se establece en Cualquier CPU)
  • instalador (Plataforma de destino establece en x86 y detectado dependencias establecen para .NET Framework (x86))

Ahora cuando instalo esta aplicación a través de setup.exe en una máquina de 64 bits, se instala en la carpeta Archivos de programa [x86]; Supongo que esta es la característica WoW64 de emular el entorno de 32 bits en una aplicación de 64 bits.

Ahora, cuando un cliente solicita convertirlo a 64 bits, ¿por qué le importa si la versión de 32 bits funciona bien a través de WoW64? convertirlo a 64 bits resultar en beneficios de rendimiento?

Y cuando trato de convertirlo a 64 bits, ¿necesito cambiarlo para todos, es decir,

  • biblioteca de clases (Plataforma de destino cambiarse a 64) (¿Qué pasa si omitir este paso?)
  • Aplicación Winform (cambie la plataforma de destino a 64) (¿Qué pasa si omito esto también?)
  • Instalador (cambie la plataforma de destino a 64) [La lista de dependencias detectadas no muestra ninguna opción .NET framework x64, ¿por qué? ]

Por favor recomiende.

Respuesta

7

No es necesario realizar ninguna conversión, su aplicación ya se ejecuta como un proceso de 64 bits. Porque usaste AnyCPU en el proyecto EXE. Lo instaló en la carpeta incorrecta, pero eso no importa mucho si ningún otro proceso intenta iniciar el suyo mediante programación. Eso es extremadamente raro.

verificar esto en Taskmgr.exe, ficha Procesos. Un proceso de 32 bits tiene * 32 después de su nombre de proceso.

Haga su cliente feliz por el cambio de configuración TargetPlatform del proyecto de instalación de 64 bits por lo que se instala en c: \ archivos de programa. Te toma unos minutos.

+0

Sí, veo que el nombre del proceso no tiene ningún * 32, incluso si la plataforma de destino es anycpu. Pero ¿cómo es ese requisito previo es .NET Framework 2.0 (x86) y todavía se está ejecutando como 64 bits. – EagerToLearn

+0

Eso es porque el instalador para .NET 2.0 que está en su máquina solo puede instalar la versión x86. Asegúrese de seleccionar .NET 3.5 SP1 en su lugar, crea un instalador mucho más pequeño. Utiliza Internet para descargar .NET, si es necesario. Una versión de 64 bits de Windows ya tiene .NET preinstalado por cierto, así que deshabilitar la dependencia también está bien.Y la razón por la que no hay instalador x64 disponible. –

+0

Muy claro, preciso y preciso. Gracias – EagerToLearn

4

Puede dejar los proyectos de código .NET en AnyCPU, sin embargo, para instalar en 64 bits sin tocar el material WOW de 32 bits que necesita para cambiar la propiedad del proyecto instalador que usted menciona.

Si tiene acciones personalizadas en el instalador, puede que no funcionen cuando cambie a 64 bits. Puede obtener un BadImageFormatException. Para resolver esto, es necesario que faff con el MSI resultante:

http://adamhouldsworth.blogspot.com/2010/10/64bit-custom-actions.html

no va a hacer mucha diferencia al cliente si su aplicación es independiente. No hay beneficio de rendimiento gratuito, aparte del acceso a más RAM, cuando se va a 64 bits (aunque el JIT tiene diferentes tipos de optimizaciones disponibles).

La única situación que he visto donde se requiere 64 bits es cuando consume esa DLL en otra aplicación, no puede mezclar bit-ness en un solo proceso.

Actualización: quizás la falta de un requisito previo de marco de 64 bits se deba a que está utilizando VS 2005?

http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/7b00f4e9-64e3-4fb6-9906-880820ecda92

+0

pero ¿por qué no veo la opción .NET Framework 2.0 (64 bits) en el cuadro de diálogo Dependencias detectadas? – EagerToLearn

+0

@EagerToLearn sin un proyecto delante de mí con un instalador, realmente no puedo responder, lo siento. –

+0

Al crear un instalador de 64 bits, ¿no debería esperar ver una opción para .NET Framework 2.0 (x64) en el cuadro de diálogo PREREQUISITOS? – EagerToLearn

2

64 bits puede o no puede dar diferencias de rendimiento. Una aplicación de 64 bits también puede utilizar (camino) más memoria que una aplicación de 32 bits.

Si ejecuta un exe AnyCpu en un sistema operativo de 64 bits, debería iniciarse en 64 bits (consulte en el administrador de tareas, los procesos de 32 bits se anexan con * 32).Si configura la aplicación en x64, la biblioteca debe ser x64 o AnyCpu.

Si usted no tiene referencias nativas x64 sólo se puede dejar el EXE y DLL como Cualquier CPU, pero tendrá que modificar la configuración para x64.

Como para el marco, en una máquina x64 (que es el único lugar una aplicación x64 se ejecutará de todos modos), el marco incluye siempre tanto 32 y 64 bits, que se encuentra en C: \ Windows \ Microsoft.NET \ Framework y Framework64 respectivamente.

+0

Y qué decir de la dependencia de .NET Framework, no veo ninguna opción para NET Framework 2.0 (64 bits) en Dependencias detectadas de diálogo – EagerToLearn

+0

Mi máquina es dev 32 bits, y al crear el instalador para una aplicación de 64 bits, no veo esa opción para .NET Framework 2.0 (64 bit) en el diálogo de dependencias detectadas. ¿Qué debo hacer para eso? – EagerToLearn

3

Ahora cuando instalo esta aplicación a través de setup.exe en una máquina de 64 bits, se instala en la carpeta Archivos de programa [x86]; Supongo que esta es la función WOW de emular el entorno de 32 bits en una aplicación de 64- bits.

No, NO tiene NADA que ver con el programa, solo con el instalador.

• Instalador (Plataforma de destino establecido en X86 y dependencias detectadas destinados para .NET Framework (x86))

32 bits instalador installes en la carpeta de 32 bits para los programas, regarless si el programa es 32 o 64 bit.

Lamentablemente no se puede tener un instalador haciendo ambas cosas - que necesita un instalador para 32 y uno de 64 bits en concepto, por diseño.

Esto es totalmente una decisión de diseño por parte de MSI y, de nuevo, no tiene nada que ver con el programa en absoluto.

Cuestiones relacionadas