为什么通过C＃interop获取COM +组件需要这么长时间？

我用下面的库，引用我的COM +组件：为什么通过C＃interop获取COM +组件需要这么长时间？

using System; 
using System.Runtime.InteropServices; 

namespace ServiceLib 
{ 
    [ClassInterface(0)] 
    [Guid("9DA56255-697A-11D4-935C-00105AD43C9D")] 
    [TypeLibType(2)] 
    public class ServiceClass : IServiceManager, ServiceManager 
    { 
     public ServiceClass(); 
     ... 
    } 
}

在我的代码，我引用它，像这样：

ServiceClass serviceClass = new ServiceLib.ServiceClass();

但是，它可能需要长达5分钟搞定物体。我的COM +组件是服务包装器，围绕着Windows服务。所以，基本上，当某些东西创建COM +引用时，我希望Windows服务启动它，但它不会。与它关联的任何.exe进程都没有。所以从字面上看，没有什么能够说我的系统正在发生5分钟，直到上面的行返回COM +对象。

来源

2014-03-12 Alexandru

延迟通常与网络超时有关。使用[Mark Russinovich的博客]（http://blogs.technet.com/b/markrussinovich/）中演示的故障排除技术来找出潜在原因。 –

@HansPassant它的所有地方。 – Alexandru

看起来问题是COM +组件的基础进程很早就死掉了，而且没有足够的时间在我的末端捕获它（检查时使用，使用Windows中的事件查看器）。它之所以死亡，是因为多个进程试图创建一个对它的引用，并且由于同步问题围绕多个进程尝试获取它的事实而导致构造器失败！

编辑：在一个单独的控制台应用程序中，我测试了这个问题，我在三个新线程中创建了组件的引用，并且the odd time I do see this issue that is a known problem around COM+, related to multiple user accounts creating too many COM+ references。

再次编辑：我设法解决所有我的问题，通过在我的windows服务上发布一个服务启动，该服务托管一个COM +对象，然后创建对它的任何引用。

最终编辑：真正的问题是，COM +对象并没有创建一个合适的单身本身，它正在AtlAdvise调用上产生一个竞争条件......上面的解决方案的工作原理是确保没有竞争条件产生。通常我会去创建线程安全代码。但是，唉，这不是我的问题，因为我正在使用别人的API。

来源

2014-03-12 14:29:46 Alexandru

为什么通过C＃interop获取COM +组件需要这么长时间？

回答

相关问题