为什么不能在.NET COM库中通过COM在.NET中使用？ [英] Why can't a .NET COM library be used via COM in .NET?

问题描述

现在，我知道，如果库是.NET中，这是一个毫无意义的一点通过COM访问它，但是，我有点困惑，因为如果我要问别人写库，并通过将其暴露COM，那人应该自由地与任何语言做到这一点。

Now, I'm aware that if the library is in .NET, it's a little pointless to access it via COM, however, I am a bit perplexed because if I were to ask someone to write a library and expose it via COM, that person should be free to do so with any language.

这不应该的问题对我来说它的语言，COM库是用，所以它为什么重要？

It shouldn't matter to me which language that COM library is written in, so why does it matter?

作为参考，这是当你使用TLBIMP从一个.NET库中生成的.tlb文件会发生什么：

For reference, this is what happens when you use tlbimp on a .tlb file generated from a .NET library:

C:\dev>tlbimp test.tlb
Microsoft (R) .NET Framework Type Library to Assembly Converter 4.0.30319.1
Copyright (C) Microsoft Corporation.  All rights reserved.

TlbImp : error TI1029 : Type library 'test' was exported from
a CLR assembly and cannot be re-imported as a CLR assembly.

此外，我的测试COM库使用的IUnknown，仅支持早期绑定的COM互操作。

Additionally, my test COM library uses IUnknown, supporting only early-bound COM interop.

推荐答案

TLBIMP是问题的开始。

tlbimp is only the beginning of the problem.

每一个COM可见的.NET对象实现IManagedObject。尝试通过COM接口来调用的对象，每次，.NET做了的QueryInterface IManagedObject，并且如果成功的目的是展开的和直接访问来代替。消除这样的互操作调用被认为是一个性能优化。

Every COM-visible .NET object implements IManagedObject. Every time you try to call an object through a COM interface, .NET does a QueryInterface for IManagedObject, and if it succeeds the object is unwrapped and accessed directly instead. Eliminating the interop call in this way is considered a performance optimization.

这是基于COM的互操作场景中的多个组件可以使用.NET语言实现一个严重的问题。如果每个.NET组件实现了COM接口的它自己的TLBIMP生成版本，他们将无法与对方使用该接口进行通信。虽然接口的每个tlbimp'ed副本具有相同的COM GUID，.NET认为这些不同的接口。 正确的解决这个问题的方法是定义一个主互操作程序集COM接口，并有充分的.NET实现的组件使用相同的接口的副本，但如果有部分开发商之间没有协调，这是pretty的可能性不大发生。

This is a serious issue in COM-based interop scenarios where multiple components may be implemented in .NET languages. If each .NET component implements its own tlbimp-generated version of the COM interface, they will be unable to communicate with each other using that interface. Even though each tlbimp'ed copy of the interface has the same COM GUID, .NET considers them separate interfaces. The "correct" solution to this problem is to define the COM interface in a primary interop assembly, and have every .NET-implemented component use that same copy of the interface, but if there's no coordination between component developers that's pretty unlikely to happen.

此问题在<一次强调由微软开发href="http://blogs.msdn.com/b/jmstall/archive/2009/07/09/icustomqueryinterface-and-clr-v4.aspx">http://blogs.msdn.com/b/jmstall/archive/2009/07/09/icustomqueryinterface-and-clr-v4.aspx连同用于.NET 4的溶液中，但它是基于一个$ P $对发行版本和在最终的不工作。我不知道其他地方，它已经承认微软。

This problem was once highlighted by a Microsoft developer at http://blogs.msdn.com/b/jmstall/archive/2009/07/09/icustomqueryinterface-and-clr-v4.aspx along with a solution for .NET 4, but it was based on a pre-release version and doesn't work in the final. I'm not aware of anywhere else it's been acknowledged by Microsoft.

一种解决办法是放弃在.NET到.NET场景的接口和使用反射来代替。这可能工作在很多情况下，但当然不是很高性能。可能是最好的解决办法是使用非托管code聚集你的每个管理组件，并拒绝尝试进行的QueryInterface IManagedObject。这类似于什么在上面的博客中描述的，但不依赖于.NET功能在该博客描述的不再起作用。

One solution is to forego the interface in the .NET-to-.NET scenario and use reflection instead. This may work in many cases but of course isn't very performant. Possibly the best solution is to use unmanaged code to aggregate each of your managed components and reject attempts to QueryInterface for IManagedObject. This is similar to what's described in the above blog entry, but doesn't rely on .NET features that no longer work as described in that blog.

在.NET互操作行为，国际海事组织，pretty的可怕，并明确违反了COM的规则（同IID ==相同的接口，并且不应该关心什么语言对象实施）。但.NET已经表现得这样从一开始就没有从这种行为咬伤开发量的反馈已经改变人的思想在.NET团队。

The .NET interop behavior is, IMO, pretty terrible, and clearly violates COM rules (same IID == same interface, and shouldn't have to care what language the object is implemented in). But .NET has behaved this way from the beginning and no amount of feedback from developers bitten by this behavior has changed the minds of anyone on the .NET team.

这篇关于为什么不能在.NET COM库中通过COM在.NET中使用？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！