的Lync:AVModality.VideoChannel的视频窗口为空成功后调用BeginStart(收到COMException HRESULT:0x80029C4A TYPE_E_CANTLOADLIBRARY) [英] Lync: VideoWindows of AVModality.VideoChannel are null after successfully calling BeginStart (COMException HRESULT: 0x80029C4A TYPE_E_CANTLOADLIBRARY)

查看:511
本文介绍了的Lync:AVModality.VideoChannel的视频窗口为空成功后调用BeginStart(收到COMException HRESULT:0x80029C4A TYPE_E_CANTLOADLIBRARY)的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

目前,我们正在试图将的Lync通信(的Lync SDK 2010)到我们的应用程序和我们的 CaptureVideoWindow运行与视频窗口(一期, RenderVideoWindow )的 AVModality 的VideoChannel :他们总是空,即使在成功调用 BeginStart 。连接是绝对成立。我们可以谈。我们自己的视频显示在远程Lync客户端。 AVModalityState 连接 VideoChannelState 云连接接收到<$ C $ 。C>发送

We are currently trying to incorporate Lync communication (Lync SDK 2010) into our application and we have run into an issue with the VideoWindows (CaptureVideoWindow, RenderVideoWindow) of the AVModality's VideoChannel: They are always null, even after successfully calling BeginStart. The connection is definitely established. We can talk. Our own video is shown in a remote Lync client. AVModalityState is Connected. VideoChannelState goes from Connecting to Receive to Send.

这无关紧要,以及我们如何试图访问这些:直接在 BeginStart 的AsyncCallback BeginStart ,以应对各种状态变化或响应外部触发(用户点击事件);在主/ UI线程或在事件/回调线程。这两个视频窗口总是空。

It does not matter when and how we try to access them: Directly after BeginStart, in the AsyncCallback of BeginStart, in response to various state changes or in response to an external trigger (user click event); in the main/UI thread or in an event/callback thread. The two video windows are always null.

在这个示例应用程序为%ProgramFiles%\Microsoft Lync\SDK\Samples\AudioVideoConversation,一切都会按计划:当 BeginStart 完成后,我们可以访问非空的视频窗口。在我们的小独立的工程样机,它的工作原理了。但在我们的实际应用中,事实并非如此。

In the example application "%PROGRAMFILES%\Microsoft Lync\SDK\Samples\AudioVideoConversation", everything works as intended: As soon as BeginStart has finished, we can access the non-null video windows. In our little stand-alone prototype project, it works, too. But in our real application, it does not.

我们有双重检查一切,我们确实已用完什么可能导致这个问题的想法。

We have double checked everything and we have really run out of ideas of what might cause this problem.

任何想法,任何提示?凡是我们应该知道的?

Any ideas, any hints? Anything that we should be aware of?

(链接到相应的MSDN论坛线程)

更新(4日2012年7月,15:46 CET):

Update (4th July 2012, 15:46 CET):

当我们一起来看看在VideoChannel的成员,我们会发现一个内部收到COMException发生在Microsoft.Office.Uc:加载DLL时出错,HRESULT:0x80029C4A(TYPE_E_CANTLOADLIBRARY)。在附截图

When we take a look at the members of the VideoChannel we find that internally a COMException occured in "Microsoft.Office.Uc": Error loading DLL, HRESULT: 0x80029C4A (TYPE_E_CANTLOADLIBRARY). More details in the attached screenshot.

我们做了这个错误一些研究,但没有发现任何对我们的工作。任何想法是什么原因导致了异常

We did some research on this error, but found nothing that worked for us. Any ideas what causes the Exception?

更新(9日2012年7月,欧洲中部时间16:43):

Update (9th July 2012, 16:43 CET):

我们做了一些进一步的测试...

We did some further testing...

我们的软件包括一个主要的应用,并通过的 MEF 。我们创建了一个最小的测试程序,使视频通话:视频窗口没有工作(如预期)。但是,当我们把相同的代码,并建立我们的架构之外的独立的解决方案,那么它的工作。因此,它与环境,而不是代码的问题。

Our software consists of one main application and many plugin-like "apps" loaded via MEF. We created a minimal test app that makes a video call: The video windows did not work (as expected). But when we took the identical code and created a separate solution outside of our architecture, then it did work. So, it was an issue with the environment, not the code.

起初,我们怀疑MEF可能是问题。所以,我们砍死的Lync代码到我们的主要应用 - 绕过整个应用程序的体系结构。仍然没有工作。

At first, we suspected MEF might be the problem. So, we hacked the lync code into our main application - circumventing the whole app architecture. Still not working.

然后,我们切掉了我们的整个系统,点点滴滴,直到我们终于到达一个点,它的工作。以下错误轨道几次之后,我们终于找到了罪魁祸首...... Quartz.NET

Then we sliced off our whole system, bit by bit, until we finally reached a point where it did work. After following wrong tracks several times, we finally found the culprit... Quartz.NET!

有关一些奇怪的原因装配参考的Quartz.dll v.1.0.3.3的存在本身,即使没有石英一行代码,使视频窗口到不行。令人难以置信,但它是100%可重复的。如果我们把前面提到的测试解决方案,什么也不做,但添加引用,它停止工作。

For some strange reason the mere presence of an assembly reference to the Quartz.dll v.1.0.3.3, even without a single line of Quartz code, causes the video windows to not work. Unbelievable, but it's 100% reproducible: If we take the previously mentioned test solution and do nothing but add the reference, it stops working.

任何想法,这样的事情是如何可能吗?

Any idea how such a thing is possible?

推荐答案

我们解决了它!有点。到Quartz.NET DLL的引用在某种程度上造成了问题。更多详细信息在更新的问题。

We solved it! Kind of. A reference to a Quartz.NET DLL somehow caused the issue. More details in the updated question.

现在,我们已经删除了使用石英组件。目前,我们并不需要它。

For now, we have removed the component that used Quartz. We currently do not need it.

但我还是有兴趣进一步投入仅仅提到是如何导致这样的问题。

But I'm still interested in further input how a mere reference can cause such an issue.

这篇关于的Lync:AVModality.VideoChannel的视频窗口为空成功后调用BeginStart(收到COMException HRESULT:0x80029C4A TYPE_E_CANTLOADLIBRARY)的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆