Компонент COM+, вызывающий другие компоненты COM+ - "Не удается загрузить тип"

У меня есть две сборки.NET, которые зарегистрированы как компоненты COM+, и я тестирую их из обычного тестового набора консольного приложения;

Dim objFirst As New MyFirstComponent() 'COM+ initialisation
Dim RC As Boolean = objFirst.GetValue()

Вызов метода выполнен успешно. Это определение MyFirstComponent;

<ProgId("MyFirstComponent")> _
<Guid("...")> _
<ClassInterface(ClassInterfaceType.None)> _
<Transaction(TransactionOption.Supported)> _
Public Class MyFirstComponent
    Inherits ServicedComponent
    Implements IMyFirstComponent

    Public Function GetValue() As Boolean Implements IMyFirstComponent.GetValue
        Dim objSecond As New MySecondComponent() 'COM+ initialisation
        Dim RC As Boolean = objSecond.GetValue()
        Return RC
    End Function

End Class

В момент инициализации MySecondComponent я получаю исключение RemotingException со следующим сообщением;

Невозможно загрузить тип 'MySecondComponent', ..., Version=..., Culture= нейтральный, PublicKeyToken=...'

Все сборки тоже строго названы. Я не могу понять, почему я могу успешно запустить вызов метода для первого компонента, но когда он пытается впоследствии загрузить сам второй компонент, он не может разрешить тип.

В качестве идентификатора, если я запускаю код из тела "GetValue()" в моем тестовом жгуте, он выполняется так, как ожидалось. Кажется, что проблема возникает только после того, как вещи переместились в сферу компонентов COM+, вызывая другие компоненты COM+.

Обновить

Я думаю, что сейчас сужаюсь в проблеме. Похоже, что COM+ что-то сохранял в процессе, и мне пришлось вручную завершать работу приложений COM+ из окна Component Services, прежде чем запускать на нем свой клиент. Раньше проблема была в том, что я тестировал клиент каждый раз, когда менял что-то (например, добавлял сборку в GAC), и по какой-то причине COM+ все еще считал, что сборка не может быть найдена. Завершение работы приложения, добавление необходимых сборок в GAC и запуск клиента снова работали, как и ожидалось.

Это было хорошо для моего небольшого доказательства концепции клиента. Поэтому я вернулся к своему реальному коду и опробовал его, но теперь у меня появляется другая странная проблема. Мои приложения COM+ сейчас не могут найти свои обычные ссылки на проекты. Я действительно не хочу идти по пути добавления ВСЕГО, что они ссылаются на GAC, поэтому я сейчас пытаюсь понять, почему мои обычные ссылки, не относящиеся к COM+, не разрешаются.

Источник

3 ответа

Решение

Я наконец нашел решение проблемы, описанной выше. Я отвечаю на этот вопрос сам, чтобы спасти кого-то еще от боли, через которую я прошел, пытаясь заставить это работать.

  • Перейдите в Службы компонентов> Приложения COM+> YourComApplication

  • Откройте окно свойств для YourComApplication и перейдите на вкладку "Активация".

  • В разделе "Корневой каталог приложения" укажите путь, по которому находятся ваши библиотеки DLL.

  • Создайте файлapplication.manifest для вашего приложения COM+ и поместите его в тот же каталог, что и выше. Пример файла выглядит так;

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1"
manifestVersion="1.0">
</assembly>
  • Этот последний шаг - то, что я пропустил прежде, и это решение не будет работать без него.

Также убедитесь, что у вас есть отдельный каталог для каждого из ваших приложений COM+. Этот подход позволит вам иметь несколько приложений COM+, основанных на сборках.NET, вызывающих друг друга без необходимости быть в GAC.

Источник

Вы смотрели на использование regasm для регистрации сборок для доступа с COM. Я не уверен, но это может быть связано с передачей параметра /codebase при регистрации сборки. Это стоит попробовать. Надеюсь это поможет.

Источник

Хотя вы, очевидно, решили проблему с помощью шагов, включенных в ответ, эта проблема также может возникнуть, если у вас есть версия PowerShell, которая не совместима со сборкой, которую вы пытаетесь загрузить.

Например, у вас может быть сборка, нацеленная на.NET Framework 4.5.1, но используемая версия PowerShell - версия 2.0. Если вы обновите версию до 4.0 или 5.0, у вас не должно возникнуть проблем.

Источник
Другие вопросы по тегам