Updating Visual Studio generated proxy classes for EWS development.

  • Article

Something I would like to highlight are issues with generated proxy classes for EWS development. We support Visual Studio generated proxy classes for EWS development – no other proxy generated classes are supported for EWS development.  I'm going to provide some basic information so that you have a starting point for cases involving EWS proxy classes.  The book Inside Exchange Web Services 2007 is the only book I know of on the topic and it was written by the Exchange Devs.

If you run into EWS code which uses an ExchangeServiceBinding object then it's likely going to be code using proxy classes generated using Visual Studio (VS).  VS can generate proxy classes (basically an API) to interact with a web service just by adding a web reference to the WSDL of the service.  When Exchange 2007 first launched most of our EWS cases were either ones with proxy classes or raw EWS SOAP POSTs.  The EWS Managed API didn't come out until well after the release of Exchange 2007.

Using EWS Proxy Classes in Exchange 2010
https://msdn.microsoft.com/en-us/library/office/dd877040(v=exchg.140).aspx

Creating a Proxy Reference By Using Visual Studio 2005 or Visual Studio 2008
https://msdn.microsoft.com/en-us/library/office/bb408520(v=exchg.140).aspx

Setting Up the ExchangeServiceBinding Proxy Class in Exchange 2010
https://msdn.microsoft.com/en-us/library/office/bb408524(v=exchg.140).aspx

Getting Started with EWS Proxy Programming in Exchange 2010
https://msdn.microsoft.com/en-us/library/office/bb408522(v=exchg.140).aspx

Creating an EWS Client Application in Exchange 2010
https://msdn.microsoft.com/en-us/library/office/bb408521(v=exchg.140).aspx

One of the issues with proxy classes is that the classes are based-upon an EWS version.  If you want to use features which came out in a later version of EWS, then you need to regenerate the proxies or splice in changes from another project where proxies were generated. 

One problem with generating new proxy classes is that the EWS schema been changed in the past in where newly generated proxy classes may not be fully compatible with existing code which uses them.  So, if you regenerate proxy code then you may need to do some minor tweaking to the code to compile again.  These problems are usually manifested are due to a type change of some item - I've mostly seen this issue with old code having its proxy classes generated under EWS 2013.

When I ran into this a couple of times a few years ago while updating EWSEditor, it led me to remove and replace existing proxy code in EWSEditor with raw EWS POSTs – however there was only very limited usage of proxies in that sample application and it was an easy change. I understand many companies have a huge investment in code which uses proxy generated classes and they are still supported.  For many/most of them they most likely would not be able to replace their existing code any time soon with code using the EWS Managed API or move to REST or Graph.

Please note that the introduction of features was introduced into EWS over many RTMs and service packs.  An example of one of the longest things to get implemented was EWS Impersonation, which first was introduced in Exchange 2007 SP1 and was fully implemented until Exchange 2010 SP2 (going from memory.  So, if you generated proxy classes for an older version of EWS and tried to use new features in Exchange 2010 SP2 which involve Impersonation then you would need to update your proxy classes.