Dirigido tanto a 32 bits como a 64 bits con Visual Studio en la misma solución / proyecto

Digamos que tienes la compilación de DLL para ambas plataformas, y están en la siguiente ubicación:

C:\whatever\x86\whatever.dll
C:\whatever\x64\whatever.dll

Simplemente necesita editar su .archivo csproj de esto:

<HintPath>C:\whatever\x86\whatever.dll</HintPath>

A esto:

<HintPath>C:\whatever\$(Platform)\whatever.dll</HintPath>

Entonces debería ser capaz de construir su proyecto dirigido a ambas plataformas, y MSBuild buscará en el directorio correcto para la plataforma elegida.

No estoy seguro de la respuesta total a su pregunta, pero pensé que podría señalar un comentario en la sección de Información Adicional de la página de descarga SQL Compact 3.5 SP1 viendo que está mirando x64, espero que ayude.

Debido a cambios en SQL Server Compact SP1 y versión adicional de 64 bits soporte, instalado centralmente y mixto entornos de modo de versión de 32 bits de SQL Server Compact 3.5 y 64 bits versión de SQL Server Compact 3.5 SP1 puede crear lo que parece ser problemas intermitentes. Para minimizar el potencial de conflictos, y para permitir implementación neutral de la plataforma aplicaciones del cliente, centralmente instalación de la versión de 64 bits de SQL Server Compact 3.5 SP1 usando el Archivo de Windows Installer (MSI) también requiere instalar la versión de 32 bits de SQL Server Compact 3.5 SP1 MSI file. Para aplicaciones que solo requerir nativo de 64 bits, privado implementación de la versión de 64 bits de SQL Server Compact 3.5 SP1 puede ser utilizados.

Leo esto como "incluir los archivos SQLCE de 32 bits así como los archivos de 64 bits" si se distribuye para clientes de 64 bits.

Hace la vida interesante, supongo.. debo decir que me encanta la línea "lo que parece ser problemas intermitentes"... suena un poco como " estás imaginando cosas, pero por si acaso, haz esto..."

Con respecto a su última pregunta. Lo más probable es que no pueda resolver esto dentro de un solo MSI. Si está utilizando carpetas de registro / sistema o algo relacionado, el propio MSI debe ser consciente de esto y debe preparar un MSI de 64 bits para instalarlo correctamente en una máquina de 32 bits.

Existe la posibilidad de que usted puede hacer que el producto instalado como una aplicación de 32 ti y todavía ser capaz de hacer que se ejecute como 64 bits uno, pero creo que puede ser algo difícil de lograr.

Dicho esto creo que debería ser capaz de mantener una única base de código para todo. En mi actual lugar de trabajo lo hemos conseguido. (pero se necesitaron algunos malabares para hacer que todo jugara junto)

Espero que esto ayude. Aquí hay un enlace a información relacionada con problemas de 32/64 bits: http://blog.typemock.com/2008/07/registry-on-windows-64-bit-double-your.html

Si utiliza Acciones personalizadas escritas en.NET como parte de su instalador MSI, entonces tiene otro problema.

El 'shim' que ejecuta estas acciones personalizadas siempre es de 32 bits, luego tu acción personalizada también ejecutará 32 bits, a pesar del objetivo que especifiques.

Más información y algunos movimientos ninja para moverse (básicamente cambiar el MSI para usar la versión de 64 bits de esta cuña)

Creación de un MSI en Visual Studio 2005/2008 para trabajar en un SharePoint 64

64-bit Acciones personalizadas administradas con Visual Studio

Puede generar dos soluciones de manera diferente y combinarlas después! Hice esto para VS 2010. y funciona. Tuve 2 soluciones diferentes generadas por CMake y las fusioné

Puede usar una condición para un ItemGroup para las referencias dll en el archivo de proyecto.
Esto hará que visual studio vuelva a comprobar la condición y las referencias cada vez que cambie la configuración activa.
Simplemente agregue una condición para cada configuración.

Ejemplo:

 <ItemGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' ">
    <Reference Include="DLLName">
      <HintPath>..\DLLName.dll</HintPath>
    </Reference>
    <ProjectReference Include="..\MyOtherProject.vcxproj">
      <Project>{AAAAAA-000000-BBBB-CCCC-TTTTTTTTTT}</Project>
      <Name>MyOtherProject</Name>
    </ProjectReference>
  </ItemGroup>

Una compilación. Net con dependencias x86 / x64

Mientras que todas las demás respuestas le dan una solución para hacer diferentes Compilaciones de acuerdo con la plataforma, le doy una opción para tener solo la configuración "AnyCPU" y hacer una compilación que funcione con sus DLL x86 y x64.

Tienes que escribir algún código de fontanería para esto. No pude conseguir que esto funcione con la aplicación.config. Si alguien más conoce una manera de resolverlo a través de la aplicación.config Realmente me gustaría saber.

Resolución de dlls x86/x64 correctos en tiempo de ejecución

Pasos:

1. Use AnyCPU en csproj
2. Decida si solo hace referencia a las DLL x86 o x64 en sus csprojs. Adapte la configuración de UnitTests a la configuración de arquitectura que haya elegido. Es importante para depurar / ejecutar las pruebas dentro de VisualStudio.
3. On Reference-Properties set Copiar local & Versión específica a falso
4. Deshazte de las advertencias de arquitectura agregando esto alinee el primer PropertyGroup en todos sus archivos csproj donde hace referencia a x86 / x64: <ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>None</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>

5. Agregue este script postbuild a su proyecto de inicio, use y modifique las rutas de este script sp que copia todas sus DLL x86 / x64 en las subcarpetas correspondientes de su build bin\x86 \ bin \ x64 \

   xcopy /E /H /R /Y /I /D $(SolutionDir)\YourPathToX86Dlls $(TargetDir)\x86 xcopy /E /H /R /Y /I /D $(SolutionDir)\YourPathToX64Dlls $(TargetDir)\x64

   } > Cuando iniciaría la aplicación ahora, obtendrá una excepción que la asamblea no pudo ser encontrada.

6. Registrar el AssemblyResolve evento justo al comienzo del punto de entrada de su aplicación

   AppDomain.CurrentDomain.AssemblyResolve += TryResolveArchitectureDependency;
   

   Con este método:

   /// <summary>
   /// Event Handler for AppDomain.CurrentDomain.AssemblyResolve
   /// </summary>
   /// <param name="sender">The app domain</param>
   /// <param name="resolveEventArgs">The resolve event args</param>
   /// <returns>The architecture dependent assembly</returns>
   public static Assembly TryResolveArchitectureDependency(object sender, ResolveEventArgs resolveEventArgs)
   {
       var dllName = resolveEventArgs.Name.Substring(0, resolveEventArgs.Name.IndexOf(","));
   
       var anyCpuAssemblyPath = $".\\{dllName}.dll";
   
       var architectureName = System.Environment.Is64BitProcess ? "x64" : "x86";
   
       var assemblyPath = $".\\{architectureName}\\{dllName}.dll";
   
       if (File.Exists(assemblyPath))
       {
           return Assembly.LoadFrom(assemblyPath);
       }
   
       return null;
   }
   

7. Si tiene pruebas unitarias, haga una TestClass con un Método que tenga un AssemblyInitializeAttribute y también registre el controlador de dependencia TryResolveArchitectureDependency anterior allí. (Esto no se ejecutará a veces si ejecuta pruebas individuales dentro de visual studio, las referencias no se resolverán desde el bin UnitTest. Por lo tanto, la decisión en el paso 2 es importante.)

Beneficios:

• Una instalación / Compilación para ambas plataformas

Inconvenientes: - No hay errores en tiempo de compilación cuando las DLL x86/x64 no coinciden. - Todavía debe ejecutar la prueba en ambos modos!

Opcionalmente crear un segundo ejecutable que es exclusivo para la arquitectura x64 con Corflags.exe en postbuild script

Otras Variantes para probar: - Usted no necesitaría el controlador de eventos AssemblyResolve si se asegura de lo contrario que los archivos dll obtener copiado en su carpeta binaria al inicio (Evaluar arquitectura de proceso - > mover las DLL correspondientes de x64 / x86 a la carpeta bin y viceversa.) - En el instalador evaluar la arquitectura y eliminar los binarios para la arquitectura incorrecta y mover los correctos a la carpeta bin.