COM-взаимодействие сборочных сборок

Question

Мне нужно развернуть несколько версий одного и того же проекта 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"; 
      } 
     } 
    } 
} 

Answer 1

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

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

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

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

Answer 2

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