2015-10-04 2 views
0

Моя конфигурация: VS2015, .NET 4.5.1, Orchard CMS, все Google nugets для 1.9.3, даже тот, который не отображается непосредственно в Visual Studio. Доступен последний календарь, который равен 1.9.2.142.Календарь не работает с версией 1.9.3

Я пробовал все, чтобы подключиться к новому календарю: API-ключ, идентификатор Cliend, учетная запись сервера. Ничего не работает. Я правильно получить маркер, но как только я пытаюсь следующий код

EventsResource.InsertRequest request = 
    service.Events.Insert(ev, calendarSettings.GoogleCalendarIds); 
Event ev2 = request.Execute(); 

Казнь замораживании Execute, ничего не посылается.

Итак, я вернулся к 1.9.2, и там код был уменьшен, единственный способ заставить его работать с ServerAccount с использованием сертификата P12.

Неужели кто-нибудь преуспел в использовании календаря с версией 1.9.3? С какой конфигурацией сборки?

+0

Ну ... спасибо за редактирование моего текста, это, безусловно, яснее. Но разве вы не боитесь, что редактирование всего, что вы делаете, может быть поручено Stack Overflow, может быть опасной тенденцией, которая может привести к проблемам? –

+0

Как вы создаете аутентификацию для кода, который замерзает? что такое ev? Что такое calendarSettings.GoogleCalendarIds? http://www.daimto.com/google-calendar-api-authentication-with-c/ – DaImTo

+0

Используя ServiceAccount с P12, замораживает 1.9.3 и тот же код с 1.9.2 работает. В моем предыдущем коде ev - событие календаря. Этот код работает с 1.9.2. Использование Fiddler кажется, что в 1.9.3 получен токен, но pgm перестает работать сразу после его получения, никакой другой запрос не отправляется, как если бы мы потеряли асинхронный вызов, отправив его без какого-либо обратного вызова, ожидающего завершения. –

ответ

0

Я также пользуюсь ServiceAccount и имел функциональный код (используя старую бета-версию 1.7x). Я обновил его до 1.9.3, и вызовы первой команды Execute зависают.

Прослеживается тот факт, что класс ClientServiceRequest использует внутренние вызовы ASYNC HttpClient, даже если вы используете предположительно синхронную команду Execute.

Просмотрите файл ClientServiceRequest.cs в файле 1.9.3, чтобы узнать, о чем идет речь.

+0

Да, я также вижу это, и я попытался напрямую вызвать ExecuteAsync с .Result, который обычно означает, что я не пропущу обратный вызов, но проблема не изменится: токен получен изнутри и ничего больше, pgm остается заблокированным в Monitor. Может быть плохое использование последнего .Net кода? –

+0

C.Surieux, Интересный в стороне - я призываю API календаря в обратном вызове AJAX в приложении WebForms. Первая попытка висит. Если я обновляю страницу и повторю попытку, она работает. Кажется, это подтверждает ваше наблюдение, что токен получен в какой-то момент, возможно, слишком поздно для первой попытки, но все еще висит на втором? –

+0

У вас лучшие результаты, чем у меня, я вызываю это из сообщения в действие контроллера, и если я заново запустил сообщение сразу после того, как скрипач обнаружил приемник-маркер-носитель (с 200), у меня такое же замораживание на Execute? –