Компонент COM +, вызывающий другие компоненты COM + - «Не удается загрузить тип» - PullRequest
2 голосов
/ 04 ноября 2010

У меня есть две сборки .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 ]

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

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

  • Перейдите в Службы компонентов> Приложения 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.

1 голос
/ 04 ноября 2010

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

0 голосов
/ 29 мая 2016

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

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

...