Office365 Exchange Webservice setup в VS2013

Question

Я пытаюсь понять концепцию «вызов Exchange Webservice в VS2013», но до сих пор не удалось.

Мне был присвоен новый адрес asmx для MS-exchange WS, который я должен был вызвать в VS2013. Я должен был изменить это со старого адр. (это сработало хорошо) на наш старый внутренний Exchange для этого нового облачного облака EWS. Но я не могу понять, что я должен сделать, чтобы он работал.

Наряду с URL-адресом EWS мне дали пароль и имя пользователя.

Также я добавил «Инструменты API Microsoft Office 365 для Visual Studio 2013».

Теперь, когда я хочу добавить свой сервис, ссылка. к моей службе proj. Я иду «Add | Connected service» (новая опция после addOn). Затем я вижу диалог в VS, содержащий только один вариант «Зарегистрировать приложение»?!?!. Что это за фигня? Моя первая проблема заключается в том, почему этот диалог отличается от того, что это введение показывает Using the tool. ... ЧТО APP?!? Это не приложение для начала - это веб-решение. Это единственное, что я могу сделать на этом этапе. Можно ли мне сказать, что здесь происходит?

Все, что я хочу, это:

1. Добавить 365Exchange WS (EWS) на мой Proj.
2. Передайте его по моим учетным данным.
3. Сделать прокси-сервер и позвонить ему.

У меня такое чувство, что мне нужно войти в учетную запись MS, где хранятся эти службы, возможно, используя мои учетные данные - или что-то еще?

Я НЕ вошел в учетную запись для начала.

Может кто-нибудь, пожалуйста, сообщите мне, какие шаги необходимо предпринять, чтобы добавить EWS.

---

Чтобы быть более точным - данное решение использует службу, не относящуюся к EWS, для вызова нашего корпоративного сервера Exchange. Работаю отлично! Теперь дело в том, что я должен перейти на Office365 Exchange вместо Office 2010, я думаю, что это так. Поэтому мне был предоставлен URL-адрес и этот набор ООН/ПСР.

Наше решение сегодня использует службу WCF, а не REST. Начнем с того, что у меня сложилось впечатление, что это было просто тонкое изменение URL-адреса, а затем передача учетных данных System.Net.NetworkCredential («userID», «password») для моего прокси-сервера. Но настройка его нормальным способом была БОЛЬШОЙ задачей. Я пошел «Добавить ссылку на службу ...», дал ему urm asmx. Все еще отлично на этом этапе. Начнем с того, что сказано (A):

«Серверу необходимо аутентифицировать ваш запрос. Ваши учетные данные будут отправлены на сервер в ясном тексте. Вы хотите продолжить?»

OK достаточно справедливо. Затем он запрашивает имя пользователя/пароль в диалоговом окне «Учетные данные для открытия», говорящее (B):

«Служба» https://outlook.office365.com/EWS/Exchange.asmx/ $ метаданных «требуется при использовании имени пользователя и пароля».

(на какой?). Я пишу в UN/PSWD, и он переходит в вечный цикл A-B-A-B ...

Итак, я отказался от добавления службы таким образом и предположил, что мои проблемы возникли из-за того, что мой VS2013 не был в курсе событий.Затем я добавил 365 API Tools.

Я не понимаю, почему я не могу добавить его в решение таким же образом и как обычный сервис WCF, обслуживаемый IIS. Что здесь особенного?

О Microsoft.Exchange.WebServices. Да, я хочу использовать управляемый API (я думаю). Я действительно хочу, чтобы создать обычный экземпляр прокси-сервера и передать ему учетные данные и вызвать его.

Включение asmx в IE по-прежнему дает мне «Вы создали службу». - Успех страницы, но попытка использования инструмента svcutil.exe завершается с ошибкой. Он отказывается отдать wsdl за услугу из-за жалобы некоторых метаданных.

На момент я думал, если это будет работать:

https://outlook.office365.com/EWS/Exchange.asmx?user=UN&password=PSWD

Я могу сделать все-в-код, если это необходимо. Помещение конечной точки, информации заголовка, имени пользователя, пароля, дополнений, привязок, протокола и т. Д. В чистом C# ... но этот подход SO утомителен и, возможно, напрасно.

Мой коллега, расположенный в Финляндии, говорит мне, что он работает нормально. Но здесь, в Дании, я не могу этого достичь или что-то (?). Он говорит об активной директории и UPN, но я об этом не знаю.

ЛЮБЫЕ подсказки ВЫСОКО оцениваются.

Answer 1

Мастер подключенных сервисов должен использовать новые API REST Office 365, а не для веб-служб Exchange. Если вы используете EWS, то что вам нужно изменить, зависит от того, как вы его используете.

У вас есть ссылка в вашем приложении на Microsoft.Exchange.WebServices? Если это так, вы используете управляемый API, и вам, вероятно, нужно будет только изменить то, что вы установили свойство Url объекта ExchangeService.

С другой стороны, вы добавляете ссылку на службу, которая заставляет Visual Studio читать WSDL и создавать для вас прокси-классы (которые, вероятно, будут называться как-то вроде ExchangeServicePortType или ExchangeServicePortTypeClient), то вы будете необходимо удалить старую служебную ссылку и добавить новую, используя URL-адрес ASMX, который они вам предоставили. Часть этого процесса предложит вам ввести имя пользователя и пароль для загрузки WSDL.

Answer 2

OK ... CodeProject было это - решение было, все в коде:

[TestMethod] 
public void CallEWS() 
{ 
    var ws = new ExchangeService(ExchangeVersion.Exchange2013); 
    ws.Credentials = new WebCredentials(UN, PSWD); 
    try 
    { 
    ws.AutodiscoverUrl(URL, RedirectionCallback); 
    } 
    catch(Exception e) 
    { 
    Console.WriteLine(e.Message); 
    } 

    var message = new EmailMessage(ws); 
    message.Subject = "Interesting"; 
    message.Body = "The proposition has been considered."; 
    message.ToRecipients.Add("myself@ourcorp.dk"); 
    message.SendAndSaveCopy(); 
} 

public static bool RedirectionCallback(string url) 
{ 
    // Return true if the URL is an HTTPS URL. 
    return url.ToLower().StartsWith("https://"); 
} 

Но URL должен был быть по электронной почте. Итак, URL = UN.

Использование:

C:\Program Files (x86)\Microsoft\Exchange\Web Services\2.1\Microsoft.Exchange.WebServices.dll 

using Microsoft.Exchange.WebServices; 
using Microsoft.Exchange.WebServices.Autodiscover; 
using Microsoft.Exchange.WebServices.Data; 
using Microsoft.Exchange.WebServices.Dns; 

(Мой первый Office365 WS)