Стратегия развертывания в приложении .NET, использующем COM-объекты - PullRequest
1 голос
/ 31 августа 2009

У меня есть вопрос относительно стратегии развертывания приложения .NET. В моем приложении я использую DSO (объекты поддержки принятия решений). Это файл COM DLL, который используется для доступа к серверу служб Analysis Services (версия 2000).

Я ссылался на COM из решения, и Visual Studio (на самом деле инструмент позади) прекрасно создал сборку .NET, которая обертывает доступ к объектам COM и делает ее классы доступными в .NET.

Обтекание использует CLSID для сопоставления классов COM DSO с сгенерированными объектами .NET посредством использования реестра Windows (при запуске установщика DSO в нем регистрируются CLSID всех открытых классов COM).

Проблема в том, что, когда Microsft выпускает новую версию DSO, и когда я устанавливаю эту новую версию, некоторые, не все CLSID-ы меняются в реестре, следовательно, отображение сгенерированных разрывов сборки .NET и сбой приложения.

DSO перераспределяется как часть целого пакета с именем Пакет обратной совместимости . Когда что-то меняется в этом пакете, что не обязательно связано с DSO, некоторые из классов COM получают новые CLSID. Это разочаровывает, потому что мое приложение перестает работать, даже если с новым пакетом ничего не меняется в отношении DSO. Они выпускают этот пакет довольно часто, самый новый - с установкой SQL Server 2008 Я думаю, и, вероятно, он обновляется в каждом пакете обновления.

Как мне разобраться с развертыванием в этом сценарии? Нужно ли создавать пакеты развертывания для моего приложения для каждой новой версии DSO?

1 Ответ

0 голосов
/ 31 августа 2009

Возможно, вам не нужны созданные файлы RCW .

Кажется, что позднее связывание решит твои проблемы. Создание классов-оболочек вручную может занять много времени, но это зависит от вашего шаблона использования. Вот ссылка на документ, описывающий позднюю привязку в .NET:

текст ссылки

...