#.net #visual-studio #azure #azureservicebus #sharepoint-apps
#.net #visual-studio #azure #azureservicebus #sharepoint-приложения
Вопрос:
В прошлом, когда я разрабатывал приложения, размещенные у поставщика SharePoint, которые реализуют удаленные приемники событий, я использовал служебную шину Azure для отладки кода, как упоминалось в этом https://blogs.msdn.microsoft.com/kaevans/2014/02/26/attaching-remote-event-receivers-to-lists-in-the-host-web/ , где внутри Azure я создаю новую служебную шину >> я копирую основную строку подключения следующим образом:- 
затем внутри проекта Visual Studio >> Свойства>> SharePoint >> я добавляю приведенную выше строку основного подключения к служебной шине следующим образом:- 
это позволяло мне отлаживать свой код. но на прошлой неделе, когда я попытался это сделать, я получил эти ошибки внутри Visual Studio после запуска проекта:-
Одна или несколько служб были незарегистрированы в служебной шине Microsoft Azure. Не удается зарегистрировать Services/AppEventReceiver.svc на служебной шине Microsoft Azure: не удается подключиться к удаленному серверу
следующим образом:- 
итак, я прочитал, что использование служебной шины Azure было отменено Microsoft с сентября 2018 года. но в то же время я не нашел альтернативы использованию служебной шины Azure для отладки приложения, размещенного у поставщика Sharepoint. Итак, может кто-нибудь посоветовать по этому поводу, пожалуйста?
Ответ №1:
Вы можете использовать ngrok в качестве прокси для локальной отладки вашего приложения без использования служебной шины.
Проблема с передачей localhost в Sharepoint заключается в том, что Sharepoint не может взаимодействовать с ним, как вы указали. ngrok предоставляет вам общедоступный URL, к которому может получить доступ Sharepoint, который затем перенаправляется на ваш локальный компьютер через службу ngrok.Это то же самое, что делала служебная шина — предлагала общедоступный URL-адрес, перенаправленный на ваш локальный.
Вместо регистрации localhost:44332/Services/AppEventReceiver.svc в Sharepoint вы должны зарегистрировать {id}.ngrok.io/Services/AppEventReceiver где id — это идентификатор, сгенерированный при запуске локальной службы ngrok.
Комментарии:
1. спасибо за ответ .. использование обратного прокси-сервера не будет работать, если я создаю свой удаленный приемник событий, используя шаги, упомянутые здесь blogs.msdn.microsoft.com/kaevans/2014/02/26 /… .. я получу сообщение об ошибке «Извините, что-то пошло не так при добавлении приложения»
2. и я получу эту ошибку в приложении «Сбой вызова удаленного получателя событий. Подробности: Не было прослушивания конечной точки на локальном хосте: 44332/Services/AppEventReceiver.svc , которая могла бы принять сообщение. Это часто вызвано неправильным адресом или действием SOAP. Дополнительные сведения см. в разделе InnerException, если оно присутствует.»
3. Я неправильно назвал ngrok обратным прокси вместо службы прокси. Я также добавил больше информации о том, почему этот подход работает аналогично тому, как работает отладка службы.
4. я уже пробовал ngrok appraoch, но надстройка sharepoint не была развернута правильно, где я получил эту ошибку
Details: There was no endpoint listening at https://localhost:44332/Services/AppEventReceiver.svc that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details... теперь, возможно, я чего-то не хватает,, как мне нужно зарегистрироваться{id}.ngrok.io/Services/AppEventReceiverвнутри проекта Visual Studio? в моем случае я просто оставил командное окно ngrok открытым…5. В исходном примере для регистрации приложения в Sharepoint с доменом ngrok использовался Powershell. Вот еще один пример, когда кто-то использует функции Azure в качестве получателя. Они более подробно описывают процесс настройки URL-адресов. spblog.net/post/2017/09/09 /…