O365 , EWS Managed API and ExchangeVersion

Question

If I am using the Exchange Web Services Managed API v2.2 to connect with O365 then which ExchangeVersion should I use?

It seems to me that it would make sense that I should always use the latest version as I assume O365 is always the latest version (in fact the O365 meeting request confirmation messages already have Exchange 2016 in their footers!)

var service = new ExchangeService(ExchangeVersion.Exchange2013_SP1);

Is there a recommended version to use for O365 or am I best to automatically use the latest version? (and does anyone have a source from microsoft on this?)

EDIT: This is the actual original issue in question that sparked my question

We're coming across an issue where spaces are being erroneously removed from Email Message HTML body when using O365. Our software is setting the ExchangeVersion to Exchange2013. Using fiddler we can see that the spaces are not actually removed, so it doesn't appear to be a Managed API issue. We did not previously have these issues, so I assume that something has changed at the O365 end.

However, if we change our software to use ExchangeVersion.Exchange2013_SP1 then the problem disappears.

So now I am wondering whether O365 has updated and expects us to therefore use the latest ExchangeVersion

Can anyone offer and advice on the ExchangeVersion with O365 or explain why the problem may have started and why changing ExchangeVersion would make things work again?

Sf

Microsoft have confirmed the original bug is actually an issue with O365 and are investigating. But it would still be useful to know what the policy regarding ExchangeVersion should be going forward. I presume ExchangeVersion.Exchange2016 will be coming shortly... – Sf

Answer 1

For Office 365, it should to ExchangeVersion.Exchange2013_SP1. As this MSDN article points out, you should use the latest version for Exchange Online. EWS API is a client library for Exchange Web Service(SOAP).

To add new features in each version of Exhange, EWS schema is changed. EWS schemas are backward- and forward-compatible, if you create an application that targets an earlier schema version, such as Exchange Server 2007 SP1, your application will also work against a later schema version, such as the Exchange Server 2013 SP1, but only with features defined by Exchange Server 2007 SP1 schema.

Castaway

Brilliant! Exactly what I was after. Couldn't find it for love nor money :) – Sf

Note that Office 365 will return 'strange' ExchangeVersion values in the results, so don't rely on those: #26404619 – Oglethorpe