COM-взаимодействия бок о бок сборки - PullRequest
Новая
       44

COM-взаимодействия бок о бок сборки

4 голосов
/ 22 ноября 2010

Мне нужно развернуть несколько версий одного и того же C # .NET проекта.Выходные данные проекта - это сборка взаимодействия COM, которая будет использоваться в собственном приложении.У меня проблема в том, что мне нужно развернуть несколько версий этой сборки бок о бок, но все, что я делаю, похоже, не создает разные версии.Вместо этого версии переопределяют друг друга.

Я попытался изменить GUID сборки, попытался изменить номера версий сборки, попытался восстановить ключ строгого имени сборки, попытался изменить заголовок и описание сборки.Я бы предпочел не менять GUID или имена для отдельных типов в сборке для целей управления версиями.

Как я могу гарантировать, что эти версии не переопределяют друг друга, и что я могу видеть и развертывать их параллельносторона?

Заранее спасибо! 

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";
            }
        }
    }
}

Ответы [ 2 ]

5 голосов
/ 22 ноября 2010

Я бы предпочел не менять GUID или имена для отдельных типов в сборке для целей управления версиями.

Но это точно то, что вам нужносделать, чтобы типы COM не мешали друг другу.[Guid] используется для выбора раздела реестра в HKLM \ Software \ Classes \ CLSID, где зарегистрирован класс COM.Две разные версии с одинаковым Guid будут перезаписывать ключи друг друга.В противном случае известный как DLL Ад.Для изменения открытого интерфейса требуется новый Guid, чтобы гарантировать, что клиенты, использующие старый, не умрут с невозможной диагностикой неправильного поведения.Сильное требование COM.

Пропуск атрибута [Guid] очень возможен, теперь вы оставляете его на усмотрение CLR, чтобы сгенерировать его для вас.Теперь атрибуты сборки начинают играть роль, значение guid автоматически генерируется скользким алгоритмом, который включает имя сборки и версию, а также набор методов интерфейса и их аргументы.Таким образом, гарантируя, что любые изменения автоматически создадут другую направляющую.И, как и ожидалось, другой [AssemblyVersion] будет генерировать другой [Guid].

Другой подход, который, как я предполагал, вы имели в виду под «рядом», заключается в не регистрируйте сборку, а вместо этого используйте манифест.Он должен быть встроен в клиентскую программу, вы используете элемент <clrClass> для объявления вашего класса [ComVisible].Управление версиями теперь становится подробностью развертывания.Инструкции MSDN здесь .Имейте в виду, что он должен быть встроен в программу client , а не в вашу [ComVisible] сборку.Это, как правило, проблема.

2 голосов
/ 22 ноября 2010

Попробуйте позднюю привязку к сборке взаимодействия в вашем родном приложении, если можете.Я также рекомендовал бы не генерировать интерфейс автоматически с использованием AutoDual, а вместо этого явно генерировать собственное чтение this для получения дополнительной информации.Вы можете устранить проблему, открыв regedit и выполнив поиск Guid и ProgId, чтобы увидеть, какие версии сборки были зарегистрированы.

...