Disposer d'une machine virtuelle et d'une compilation en deux phases permet de bénéficier d'un support du 64 bits quasi-automatique. Si l'on compile une assembly en Any Cpu, celle-ci sera compilée en JIT en 32 bits si elle est chargée dans un process 32 bits ou en 64 bits dans le cas d'un chargement dans un process 64 bits. De plus si une assembly a des dépendances vers des assemblys 32 bits ou vers des DLL natives 32 bits, elle se retrouvera automatiquement compilée en 32 bits même si chargée dans un environnement 64 bits.
Il faut cependant noter que cette analyse de dépendances ne concerne que les dépendances statiques et en aucun cas les dépendances dynamiques (introduites via du code).
J'ai récemment rencontré le problème à propos de l'utilisation d'un filtre DirectShow. Le filtre est instancié via un Activator.CreateInstance afin d'être manipulé et insérer au sein d'un graphe de cette manière :
/// <summary>
/// Wrapper of the HttpDestinationFilter
/// </summary>
public class HttpDestinationFilter
{
private static readonly Guid CLSID_HttpDestination = new Guid("E6788379-AAA3-4516-86EC-158B7A49EA74");
public static IBaseFilter CreateInstance()
{
return (IBaseFilter) Activator.CreateInstance(Type.GetTypeFromCLSID(CLSID_HttpDestination, true));
}
}Seul problème, lors de l'exécution de ce code sur une plate-forme 64 bits, l'instanciation peut échouer si le composant en question est en 32 bits et si l'assembly est compilée en Any Cpu.
Etant sur un Windows 64 bits, la base de registres est en grande partie divisée en deux versions, une copie pour les applications 32 bits et une autre copie pour les application 64 bits. Il est ainsi (entre autres raisons) impossible d'utiliser des composants COM 32 bits depuis une application 64 bits car le composant se retrouve introuvable du fait de la redirection. La correction du problème est simple : trouver une version 64 bits du composant en question ou alors définir manuellement la target de compilation afin d'indiquer un compilation en 32 bits.