Oui, vous pouvez cibler à la fois x86 et x64 avec la même base de code dans le même projet. En général, les choses fonctionneront si vous créez les bonnes configurations de solution dans VS.NET (bien que P/Invoke vers des DLLs entièrement non gérées nécessitera très probablement du code conditionnel) : les éléments qui, selon moi, nécessitent une attention particulière sont les suivants :
- Références à des assemblages gérés externes portant le même nom mais ayant leur propre bitness spécifique (ceci s'applique également aux assemblages COM interop).
- Le paquet MSI (qui, comme on l'a déjà noté, devra cibler soit x86 soit x64)
- Toute action personnalisée basée sur la classe d'installation .NET dans votre paquet MSI.
Le problème des références d'assemblage ne peut pas être résolu entièrement dans VS.NET, car il ne vous permet d'ajouter une référence avec un nom donné à un projet qu'une seule fois. Pour contourner ce problème, modifiez votre fichier de projet manuellement (dans VS, cliquez avec le bouton droit de la souris sur votre fichier de projet dans l'explorateur de solutions, sélectionnez Décharger le projet, puis cliquez à nouveau avec le bouton droit de la souris et sélectionnez Modifier). Après avoir ajouté une référence à, disons, la version x86 d'un assemblage, votre fichier de projet contiendra quelque chose comme :
<Reference Include="Filename, ..., processorArchitecture=x86">
<HintPath>C:\path\to\x86\DLL</HintPath>
</Reference>
Enveloppez cette balise de référence dans une balise ItemGroup indiquant la configuration de la solution à laquelle elle s'applique, par ex :
<ItemGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
<Reference ...>....</Reference>
</ItemGroup>
Ensuite, copiez et collez la balise ItemGroup entière, et modifiez-la pour qu'elle contienne les détails de votre DLL 64 bits, par exemple :
<ItemGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x64' ">
<Reference Include="Filename, ..., processorArchitecture=AMD64">
<HintPath>C:\path\to\x64\DLL</HintPath>
</Reference>
</ItemGroup>
Après avoir rechargé votre projet dans VS.NET, la boîte de dialogue Référence d'assemblage sera un peu confuse par ces changements, et vous pourrez rencontrer quelques avertissements concernant des assemblages avec le mauvais processeur cible, mais toutes vos constructions fonctionneront parfaitement.
Résoudre le problème MSI est le suivant, et malheureusement ceci sera nécessitent un outil non-VS.NET : Je préfère celui de Caphyon Installateur avancé à cette fin, car il réussit très bien l'astuce de base (créer un MSI commun, ainsi que des MSI spécifiques 32 et 64 bits, et utiliser un lanceur d'installation .EXE pour extraire la bonne version et effectuer les corrections nécessaires au moment de l'exécution).
Vous pouvez probablement obtenir les mêmes résultats à l'aide d'autres outils ou de l'outil de gestion de l'environnement. Outils Windows Installer XML (WiX) Mais Advanced Installer rend les choses si faciles (et est très abordable en plus) que je n'ai jamais vraiment regardé les alternatives.
Une chose que vous mai Les actions personnalisées de votre classe d'installation .NET constituent l'une des raisons pour lesquelles vous avez toujours besoin de WiX, même si vous utilisez Advanced Installer. Bien qu'il soit facile de spécifier certaines actions qui ne doivent être exécutées que sur certaines plates-formes (en utilisant les conditions d'exécution VersionNT64 et NOT VersionNT64, respectivement), les actions personnalisées AI intégrées seront exécutées en utilisant le Framework 32 bits, même sur les machines 64 bits.
Ce problème sera peut-être corrigé dans une prochaine version, mais pour l'instant (ou si vous utilisez un autre outil pour créer vos MSI qui a le même problème), vous pouvez utiliser le support des actions personnalisées gérées de WiX 3.0 pour créer des DLL d'action avec le bitness approprié qui seront exécutées en utilisant le Framework correspondant.
Edition : à partir de la version 8.1.2, Advanced Installer prend correctement en charge les actions personnalisées 64 bits. Depuis ma réponse initiale, son prix a malheureusement beaucoup augmenté, même s'il reste extrêmement avantageux par rapport à InstallShield et ses semblables...
Edit : Si vos DLLs sont enregistrées dans le GAC, vous pouvez également utiliser les balises de référence standard de cette façon (SQLite par exemple) :
<ItemGroup Condition="'$(Platform)' == 'x86'">
<Reference Include="System.Data.SQLite, Version=1.0.80.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139, processorArchitecture=x86" />
</ItemGroup>
<ItemGroup Condition="'$(Platform)' == 'x64'">
<Reference Include="System.Data.SQLite, Version=1.0.80.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139, processorArchitecture=AMD64" />
</ItemGroup>
La condition est également réduite à tous les types de construction, release ou debug, et spécifie seulement l'architecture du processeur.
0 votes
@Magnus Johansson : vous pouvez utiliser deux configurations pour atteindre la moitié de votre objectif. Le MSI est un peu plus difficile.