Office365 Exchange Webservice setup in VS2013

0
votes

I'm trying to grasp the concept of 'calling an Exchange Webservice in VS2013' but have failed so far.

I was given a new asmx-address to a MS-exchange WS that I was to call in VS2013. I was to change that from an old addr. (that worked a-ok.) to our old internal Exchange to this new EWS cloud-thing. But I can't understand what I have to do to make it work.

Along with the EWS url I was given a password and a username.

Also I have added the "Microsoft Office 365 API Tools for Visual Studio 2013".

Now, when I want to add my service ref. to my service proj. I go "Add|Connected service" (a new option after the addOn). Then I see a dialog in VS holding only one option "Register your app"?!?!. What the heck is that? My first concern is why is this dialog different from what this intro shows Using the tool. ... WHAT APP?!? This is not an app to begin with - this is a web solution. It is the only thing I can do in this step. Can one tell me what is going on here?

All I want is to:

  1. Add 365Exchange WS (EWS) to my proj.
  2. Hand it over my given credentials.
  3. Make a proxy and call it.

I have the feeling I have to login to an MS account holding these services - perhaps using my credentials - or something?

I'm NOT logged into any account to begin with.

Can someone please tell me the steps to take in order to add a EWS.

To be more exact - present solution use a non-EWS service for calling our corporate Exchange server. Working fine! Thing is now that I have to change to Office365 Exchange instead of Office 2010 I think it is. So I was handed an url, and this set of UN/PSWD.

Our solution use a WCF service today and its not REST. To begin with I was under the impression that it was just fine changing the url and then handing over a System.Net.NetworkCredential("userID", "password") credential to my proxy. But setting it up the normal way was a BIG challenge. I went "Add service reference..." gave it the asmx url. Still fine at this step. To begin with is says (A):

"The server needs to authenticate your request. Your credentials will be sent to the server in clear text. Do you want to continue?"

OK fair enough. Then it is asking for a username/password in a dialog called "Discovery credential" saying (B):

"The Service 'https://outlook.office365.com/EWS/Exchange.asmx/$metadata' at requires a username and password."

(at what?). I write in UN/PSWD and it goes into a eternal loop A-B-A-B...

So I gave up adding the service this way and assumed my problems originated from not having my VS2013 up to date some way. I then added the 365 API Tools.

I don't understand why I can't add it to the solution in same way and like a normal IIS hosted WCF service. What is so special here?

About the Microsoft.Exchange.WebServices. Yes I want to use the managed API (I think). What I really want is to be able to create a normal proxy instance and feeding it the credentials and call it.

Putting the asmx in IE still gives me the "You have created a service."-page success, but trying to use the svcutil.exe tool fails. It refuses to give away a wsdl for the service due to some Metadata complain.

At a point I was thinking if this would work:

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

I can do a all-in-code solution if needed. Putting endpoint, header info, username, password, addr., bindings, protocol etc. in pure C#... but this approach is SO tiresome and perhaps in vain.

My colleague, positioned in Finland, tells me it works just fine. But here in Denmark I can't reach it or something(?). He is talking about active directory and UPN but I don't know so much about that.

ANY hints is HIGHLY appreciated.

2
office365exchangewebservices

2 Answers

0
votes

The connected service wizard is to use the new Office 365 REST APIs, not for Exchange Web Services. If you're currently using EWS, what you need to change depends on HOW you are using it.

Do you have a reference in your app to Microsoft.Exchange.WebServices? If so you're using the Managed API, and you likely only need to change anywhere that you set the Url property of the ExchangeService object.

If, on the other hand, you've add a Service Reference, which cause Visual Studio to read the WSDL and create proxy classes for you (which will probably be named something like ExchangeServicePortType or ExchangeServicePortTypeClient), then you'll need to remove the old service reference and add a new one, using the ASMX URL that they gave you. Part of that process will prompt you for a username and password to download the WSDL.

0
votes

OK... CodeProject had it - solution was, all in code:

[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("[email protected]");
    message.SendAndSaveCopy();
}

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

But the URL had to be an email. So URL = UN.

Using:

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;

(My first Office365 WS)