COM+调用其他 COM 的组件组件 - “无法加载类型”

发布于 2024-09-30 18:52:03 字数 1481 浏览 1 评论 0原文

我有两个 .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=neutral,PublicKeyToken=...'

所有程序集也都是强命名的。我无法弄清楚为什么我可以成功地触发对第一个组件的方法调用,但是当它尝试随后加载第二个组件本身时,它无法解析类型。

作为旁注,如果我从测试工具中的“GetValue()”主体运行代码,它将按预期执行。似乎只有当事情进入 COM+ 组件调用其他 COM+ 组件的领域时,这个问题才会出现。

更新

我想我现在正在缩小问题范围。看来 COM+ 正在持久保存进程中的某些内容,因此我必须在针对 COM+ 应用程序运行客户端之前从“组件服务”窗口手动关闭 COM+ 应用程序。之前的问题是,每次更改某些内容(例如将程序集添加到 GAC)时,我都会测试客户端,并且由于某种原因 COM+ 仍然认为找不到程序集。关闭应用程序、将所需的程序集添加到 GAC 并再次运行客户端,效果按预期进行。

这对于我的小型概念验证客户来说很好。所以我回到我的真实代码并尝试了一下,但现在我遇到了另一个奇怪的问题。我的 COM+ 应用程序现在似乎无法找到其正常的项目引用。我真的不想继续添加他们引用 GAC 的所有内容,因此我现在正在尝试找出为什么我的正常非 COM+ 引用没有得到解决。

I have a two .NET assemblies which are registered as COM+ components and I'm testing them from a regular console application test harness;

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

The method call is executed successfully. This is the definition of 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

At the point where MySecondComponent is initialised, I get a RemotingException with the following message;

Cannot load type 'MySecondComponent', ..., Version=..., Culture=neutral, PublicKeyToken=...'

All assemblies are strongly named too. I cannot work out why I can successfully fire a method call to the first component, but when it tries to subsequently load up the second component itself, it can't resolve the type.

As a sidenote, if I run the code from the body of "GetValue()" in my test harness, it executes as expected. The problem seems to only crop up once things have moved into the realm of COM+ components calling other COM+ components.

Update

I think I am narrowing in on the problem now. It appears that COM+ was persisting something in process, and I had to manually shut down the COM+ applications from the Component Services window before running my client against it. The problem before was that I was testing the client every time I changed something (like adding the assembly to the GAC), and for some reason COM+ still believed that the assembly could not be found. Shutting the app down, adding the required assemblies to the GAC and running the client again worked as expected.

This was fine for my small proof of concept client. So I went back to my real code and tried it out, but now I am getting another strange issue. My COM+ applications seem unable to locate their normal project references now. I don't really want to go down the road of adding EVERYTHING that they reference to the GAC, so I'm now trying to work out why my normal, non-COM+ references aren't being resolved.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

七堇年 2024-10-07 18:52:03

我终于找到了解决上述问题的方法。我自己在这里回答这个问题是为了避免其他人在我尝试让它发挥作用时所经历的痛苦。

  • 转到组件服务> COM+ 应用程序 > YourComApplication

  • 打开 YourComApplication 的属性窗口并转到“激活”选项卡。

  • 在“应用程序根目录”下,提供 DLL 所在的路径。

  • 为您的 COM+ 应用程序创建一个“application.manifest”文件,并将其放在与上面相同的目录中。示例文件如下所示;


<程序集 xmlns="urn:schemas-microsoft-com:asm.v1"
清单版本=“1.0”>

  • 这最后一步是我之前错过的,如果没有它,这个解决方案将无法工作

另外,请确保每个 COM+ 应用程序都有一个单独的目录。这种方法将允许您让多个基于 .NET 程序集的 COM+ 应用程序相互调用,而无需在 GAC 中添加任何内容。

I have finally found a solution to the problem described above. I'm answering the question myself here to save anyone else the pain that I went through trying to get this to work.

  • Go to Component Services > COM+ Applications > YourComApplication

  • Bring up the properties window for YourComApplication and go to the Activation tab.

  • Under "Application Root Directory", supply the path in which your DLLs reside.

  • Create an "application.manifest" file for your COM+ application and put it in the same directory as above. A sample file looks like this;

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1"
manifestVersion="1.0">
</assembly>
  • This final step is what I had missed before and this solution will not work without it.

Also, make sure that you have a separate directory for each of your COM+ applications. This approach will allow you to have mulitple COM+ applications based on .NET assemblies calling each other without anything having to be in the GAC.

酒废 2024-10-07 18:52:03

您是否考虑过使用 regasm 来注册程序集以通过 COM 进行访问。我不确定,但这可能与注册程序集时传递的 /codebase 参数有关。值得一试。希望这有帮助。

Have you looked into using regasm to register the assemblies for access with COM. I am not sure but it may have to do with the /codebase parameter being passed when you register the assembly. It is worth a shot. Hope this helps.

残月升风 2024-10-07 18:52:03

虽然您显然通过答案中包含的步骤解决了问题,但如果您的 PowerShell 版本与您尝试加载的程序集不兼容,也可能会出现此问题。

例如,您可能有一个面向 .NET Framework 4.5.1 的程序集,但您运行的 PowerShell 版本是 2.0 版。如果您将版本升级到4.0或5.0,应该没有问题。

Although you obviously resolved the issue with the steps included in the answer, this problem can also occur if you have a version of PowerShell that is not compatible with the assembly you are trying to load.

For example, you may have an assembly targeting .NET framework 4.5.1, but the PowerShell version you are running is version 2.0. If you upgrade the version to 4.0 or 5.0, you should have no issue.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文