Lync: VideoWindows из AVModality.VideoChannel обнуляются после успешного вызова BeginStart (COMException HRESULT: 0x80029C4A TYPE_E_CANTLOADLIBRARY)

Question

В настоящее время мы пытаемся включить связь Lync (Lync SDK 2010) в наше приложение, и у нас возникла проблема с VideoWindows (CaptureVideoWindow, RenderVideoWindow) из AVModality"s VideoChannel: Они всегда нулевые, даже после успешного вызова BeginStart, Связь определенно установлена. Мы можем говорить. Наше собственное видео показывается в удаленном клиенте Lync. AVModalityState является Connected, VideoChannelState идет от Connecting в Receive в Send,

Неважно, когда и как мы пытаемся получить к ним доступ: сразу после BeginStart, в AsyncCallback из BeginStartв ответ на различные изменения состояния или в ответ на внешний триггер (событие щелчка пользователя); в основном потоке / пользовательском интерфейсе или в потоке события / обратного вызова. Два видео окна всегда нулевые.

В примере приложения "%PROGRAMFILES%\Microsoft Lync\SDK\Samples\AudioVideoConversation" все работает, как предполагалось: как только BeginStart закончили, мы можем получить доступ к ненулевым видео окнам. В нашем маленьком автономном проекте-прототипе это тоже работает. Но в нашем реальном приложении это не так.

Мы дважды проверили все, и у нас действительно закончились идеи о том, что может вызвать эту проблему.

Есть идеи, есть намеки? Что-нибудь, о чем мы должны знать?

(Ссылка на соответствующую ветку форума MSDN)

Обновление (4 июля 2012 г., 15:46 CET):

Когда мы посмотрим на членов VideoChannel, мы обнаружим, что внутри "Microsoft.Office.Uc" возникла исключительная ситуация COMException: ошибка загрузки DLL, HRESULT: 0x80029C4A (TYPE_E_CANTLOADLIBRARY). Подробнее на прикрепленном скриншоте.

Мы провели некоторое исследование этой ошибки, но ничего не нашли для нас. Есть идеи, что вызывает исключение?

Обновление (9 июля 2012 г., 16:43 CET):

Мы провели дополнительное тестирование...

Наше программное обеспечение состоит из одного основного приложения и множества плагиноподобных "приложений", загружаемых через MEF. Мы создали минимальное тестовое приложение, которое выполняет видеовызов: видео окна не работают (как и ожидалось). Но когда мы взяли идентичный код и создали отдельное решение вне нашей архитектуры, тогда это сработало. Таким образом, это была проблема со средой, а не с кодом.

Сначала мы подозревали, что MEF может быть проблемой. Итак, мы взломали код lync в наше основное приложение - обойдя всю архитектуру приложения. До сих пор не работает.

Затем мы по крупицам отрезали всю нашу систему, пока, наконец, не достигли точки, когда она заработала. Пройдя несколько раз по неверному пути, мы наконец нашли виновника... Quartz.NET!

По какой-то странной причине простое присутствие ссылки на сборку Quartz.dll v.1.0.3.3, даже без единой строки кода Quartz, приводит к тому, что видеоокна не работают. Невероятно, но это на 100% воспроизводимо: если мы берем ранее упомянутое тестовое решение и ничего не делаем, только добавляем ссылку, она перестает работать.

Есть идеи, как это возможно?

Answer 1

Мы решили это! Вид. Ссылка на Quartz.NET DLL почему-то вызвала проблему. Подробнее в обновленном вопросе.

На данный момент мы удалили компонент, который использовал Quartz. Нам в данный момент это не нужно.

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