У меня есть вопрос относительно стратегии развертывания приложения .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?