В настоящее время мы пытаемся включить Lync связи (Lync SDK 2010) в наше приложение, и мы столкнулись с проблемой, с VideoWindows (CaptureVideoWindow, RenderVideoWindow) AVModalityVideoChannel: они всегда равны нулю, даже после успешного вызова BeginStart. Связь определенно установлена. Мы можем говорить. Наше собственное видео показано на удаленном Lync-клиенте. AVModalityState является Connected. VideoChannelState От Connecting до Receive до Send.Lync: VideoWindows из AVModality.VideoChannel являются недействительными после успешного вызова BeginStart (COMException HRESULT: 0x80029C4A TYPE_E_CANTLOADLIBRARY)
Это не имеет значения, когда и как мы пытаемся получить доступ к ним: Сразу после BeginStart, в AsyncCallback из BeginStart, в ответ на различные изменения состояния или в ответ на внешний триггер (пользователь нажмет событие); в потоке основного/пользовательского интерфейса или в потоке событий/обратного вызова. Два видеоокна всегда равны нулю.
В примере приложения «% PROGRAMFILES% \ Microsoft Lync \ SDK \ Samples \ AudioVideoConversation» все работает по назначению: Как только BeginStart закончит, мы можем получить доступ к ненулевым видео-окнам. В нашем маленьком автономном прототипе проект также работает. Но в нашем реальном приложении это не так.
Мы проверили все, и у нас действительно не хватало идей о том, что может вызвать эту проблему.
Любые идеи, любые подсказки? Все, о чем мы должны знать?
(Link to corresponding MSDN forum thread)
Update (4 июля 2012, 15:46 CET):
Когда мы посмотрим на членов Видеоканал мы находим, что Внутренне COMException произошло в «Microsoft.Office .Uc ": Ошибка при загрузке DLL, HRESULT: 0x80029C4A (TYPE_E_CANTLOADLIBRARY). Подробнее в attached screenshot.
Мы сделали некоторые исследования на эту ошибку, но не нашел ничего, что работало для нас. Любые идеи, что вызывает исключение?
Update (9 июля 2012, 16:43 CET):
Мы сделали некоторые дальнейшие испытания ...
Наше программное обеспечение состоит из основного приложения и много плагинов, как «приложения» загружены через MEF. Мы создали минимальное тестовое приложение, которое делает видеозвонок: видеоокна не работали (как и ожидалось). Но когда мы взяли идентичный код и создали отдельное решение за пределами нашей архитектуры, это сработало. Таким образом, это была проблема с окружающей средой, а не с кодом.
Сначала мы подозревали, что MEF может быть проблемой. Итак, мы взломали код Lync в нашем основном приложении - обойдя всю архитектуру приложения. Все еще не работает.
Затем мы порезали всю нашу систему, понемногу, пока мы наконец не достигли точки, где она работала. После нескольких неправильных следов несколько раз мы, наконец, нашли преступника ... Quartz.NET!
По какой-то странной причине простое наличие ссылки на сборку Quartz.dll v.1.0.3.3, даже без отдельной строки кода кварца, приводит к тому, что видеоокна не работают. Невероятно, но это на 100% воспроизводимо: если мы возьмем ранее упомянутое тестовое решение и ничего не делаем, кроме добавления ссылки, оно перестает работать.
Любая идея, как такое возможно?
Возможно, вы захотите перенести информацию из обновления в свой ответ, где это будет иметь больше смысла. Это оказалось ссылкой на Quartz.NET, которая вызвала это в конце концов. – BoltClock