Com interopérant côte à côte

Question

J'ai besoin de déployer plusieurs versions du même projet C # .NET. La sortie du projet est un assemblage d'interopt COM à utiliser dans une application native. Le problème que j'ai, c'est que je dois déployer plusieurs versions de cet assemblage côte à côte, mais tout ce que je fais ne semble pas créer différentes versions. Au lieu de cela, les versions se remplacent.

J'ai essayé de changer le guid d'assemblage, j'ai essayé de changer les numéros de version de l'assembly, j'ai essayé de régénérer la clé de nom fort de l'assembly, j'ai essayé de changer le titre et la description de l'assembly. Je préfère ne pas avoir à modifier les Guid ou les noms pour les types individuels dans l'assemblage à des fins de versioning.

Comment puis-je m'assurer que ces versions ne se remplacent pas et que je peux les voir et les déployer côte à côte?

Merci d'avance!

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Runtime.InteropServices;

namespace InteropTest
{
    [Guid("...")]
    [ClassInterface(ClassInterfaceType.AutoDual)]
    public class Test
    {
        public Test()
        {
        }

        public string Version
        {
            get
            {
                return "1.0";
            }
        }
    }
}

Answer 1

Je préfère ne pas avoir à modifier les Guid ou les noms pour les types individuels dans l'assemblage à des fins de versioning.

Mais ça exactement Ce que vous devez faire pour empêcher les types de com d'interférer les uns avec les autres. Le [GUID] est utilisé pour sélectionner la clé de registre dans HKLM Software Classes CLSID où la classe COM est enregistrée. Deux versions distinctes avec le même GUID se écraseront les clés les unes et les autres. Autrement connu sous le nom de DLL Hell. Changer l'interface publique a besoin Un nouveau GUID pour s'assurer que les clients qui utilisent l'ancien ne meurent pas avec impossible de diagnostiquer la mauvaise conduite. Une exigence du rock dure.

L'omission de l'attribut [GUID] est très possible, vous laissez maintenant le CLR pour en générer un pour vous. Maintenant que les attributs d'assemblage commencent à jouer un rôle, la valeur GUID est générée automatiquement par un algorithme lisse qui inclut le nom d'assemblage et la version ainsi que l'ensemble des méthodes sur l'interface et leurs arguments. Assurant ainsi que n'importe quel Les changements produisent automatiquement un GUID différent. Et, comme prévu et requis, une autre [assemblée] générera un [GUID] différent.

Une autre approche, qui est ce que je supposais que vous vouliez dire avec «côte à côte», c'est de ne pas Enregistrez l'assemblage mais comptez sur un manifeste à la place. Il doit être intégré dans le programme client, vous utilisez le <clrClass> élément pour déclarer votre classe [Comvisible]. Le versioning devient désormais un détail de déploiement. Le mode de MSDN est là. Gardez à l'esprit qu'il doit être ancré dans le client Programme, pas votre assemblée [Comvisible]. Cela a tendance à être un problème.

Answer 2

Essayez la liaison tardive à l'assemblage d'interopt dans votre application native si vous le pouvez. Je conseillerais également de générer automatiquement l'interface en utilisant autodual et générer explicitement votre propre lecture cette pour plus d'informations. Vous pouvez dépanner le problème en ouvrant Regedit et en recherchant le GUID et le PROGID pour voir quelles versions de l'assemblage ont été enregistrées.