none
How to use the Exchange 2013 .NET classes directly (i.e. NOT POWERSHELL) RRS feed

  • Question

  • Powershell is great for system admins wanting to automate things, but personally I think it absolutely sucks for .NET developers when Powershell is apparently the only "API" available for programming against a particular system. For a long time I've wanted to create some Exchange related utilities - server reporting tools, monitoring tools, etc, but it seems that for us .NET developers this is not possible without shelling out to Powershell cmdlets. This baffles me as the Powershell cmdlets are using Exchange .NET classes internally so why on earth can't we just use those same Exchange .NET classes? I know technically we can add a reference to them, but we're not allowed to redistribute them and there's no documentation on how to use them.

    With Exchange 2013 things looked a little more promising as the classes and namespaces are at least documented here: http://msdn.microsoft.com/en-us/library/exchange/dn186243(v=exchg.150).aspx but there's no examples of how to actually use them or any indication of where to start.

    So am I just missing something or is there still no way for a .NET developer to program against Exchange server (and I do mean the server side, I'm not interested in sending emails or adding calendar appointments etc which is what the EWS .NET Managed API seems to be aimed at) without using Powershell cmdlets?


    My website (free apps I've written for IT Pro's) : www.cjwdev.co.uk My blog: cjwdev.wordpress.com

    Thursday, July 25, 2013 3:11 PM

All replies

  • Should I assume from the lack of answers that this is simply not possible?

    My website (free apps I've written for IT Pro's) : www.cjwdev.co.uk My blog: cjwdev.wordpress.com

    Sunday, August 18, 2013 10:44 PM
  • Actually, given the apis available (2010 did have them too, just spread accross several underdocumented SDKs) I'd assume it to be possible. I don't know how, though.

    Maybe the underwhelming number of responses is owed to it being a complex matter and those in the know don't have the time to spare to explain it on the forums. At least that'd be my assumption, as - as I said - I myself don't know how to code directly against the Exchange server.

    Good luck with your search though.


    There's no place like 127.0.0.1

    Monday, August 19, 2013 7:57 AM
  • Yeah that's kind of what I assumed as well - but it seems pretty rubbish that learning how to program against one of Microsoft's most popular server side products is this difficult. I mean if its not documented on MSDN and no one on these forums knows then I don't know where to look next really. Even if I did figure out how to use the Exchange .NET libraries directly, there's still the issue of not being allowed to redistribute them. 

    My website (free apps I've written for IT Pro's) : www.cjwdev.co.uk My blog: cjwdev.wordpress.com

    Monday, August 19, 2013 1:44 PM