1. The hard-coded URL might point to the URL of a Client Access server that is in a different site from the user’s mailbox. Accessing a Client Access server in a different site from a user’s mailbox results in poorer performance and greater complexity than accessing a Client Access server in the same site as the mailbox. The only way to ensure that you are accessing a Client Access server in a particular user’s site is to use Autodiscover.
2. We may change the URL for various Web services as we consolidate them, or break them up for better architecture between roles, which will complicate migration to later versions of Microsoft Exchange Server.
3. The corporate address could change namespaces (this doesn’t happen often, but we have occasionally changed our namespace at Microsoft). For example, https://mail.contoso.com could become https://portal.contoso.com.
Let me explain a little more about why accessing a Client Access server in a different site from a user’s mailbox is not a good idea. If your enterprise has multiple Active Directory sites (i.e. branch offices that are running Exchange Server 2007), Exchange Web Services in the initial release version of Exchange 2007 will be making cross-site remote procedure calls (RPCs) from the Client Access server that you are accessing to the mailbox in the site where a user is located. Cross-site RPCs are not recommended because RPC traffic is very chatty and high latency networks between sites will degrade the performance of Exchange Web Services significantly. In Exchange 2007 Service Pack 1 (SP1), we have gone the route of Outlook Web Access and ActiveSync and disabled cross-site RPC functionality. Now cross-site calls will fail unless an Exchange 2007 SP1 Client Access server is in the same site as the user mailbox that is set up for EWS proxy. EWS proxy makes these requests more efficient by sending a single HTTP request rather than multiple RPC requests. However, relying on EWS proxy to do the work of getting your request to the right site is also not an ideal solution because it puts unnecessary load on the proxying Client Access server. You can avoid this unnecessary load by making the request to the appropriate Client Access server yourself.
We have some good resources about using Autodiscover. For a sample application that includes downloadable source code that implements an Autodiscover client for you, see Autodiscover Sample Application. For information about the structure of an Autodiscover request, see Autodiscover Request.
One thing to note: Autodiscover is not a SOAP-based Web service. It just uses plain old XML (POX).
Look for more information that describes Autodiscover in more depth soon. Until then, use the examples referenced earlier and always Autodiscover.
It has come to our attention that there has been some confusion over the mention of EWS.dll in the SDK documentation and Intellisense file. Where can people find it? Actually, you get to generate it. The Exchange 2007 SDK describes how to generate proxy classes by using the Add Web Reference. This may be fine for some of you, but others may want more flexibility with their proxy classes. This is where wsdl.exe comes into the picture.
Wsdl.exe parses schema and WSDL files to generate Microsoft .NET code files. These code files contain the types that act as proxies for the serialization and deserialization of the XML messages that are sent to and from the Exchange server. Wsdl.exe is included in the .NET Framework SDK and with Visual Studio 2003 and 2005. Different proxy generators create different object models; in this discussion, I will focus on wsdl.exe version 2.0.50727.42, the version that is included with Visual Studio 2005.
Instead of using wsdl.exe, you can use the Add Web References option in Visual Studio 2005 to create proxy classes. (This option will still be available in Visual Studio 2008, except that it will be well hidden). I prefer to use wsdl.exe to generate my proxy classes, for two reasons: 1) I can easily extend the proxy classes to make them easier to use, and 2) I can reuse my compiled DLL in all my Exchange Web Services projects. If I use the Add Web References option in Visual Studio, I have to regenerate the proxy classes for each project and therefore I lose any modifications that I made to the autogenerated classes. Oh, and remember that changes made to autogenerated classes are not supported by Microsoft; you are on your own with those modifications.
Let's start by finding wsdl.exe. By default, the Windows SDK installs it to C:\Program Files\Microsoft SDKs\Windows\v6.0\Bin\wsdl.exe. You can also access wsdl.exe by using the Visual Studio 2005 Command Prompt. To find the Visual Studio 2005 Command Prompt, from the Start Menu, choose All Programs | Microsoft Visual Studio 2005 | Visual Studio Tools | Visual Studio 2005 Command Prompt. Wsdl.exe has been added to the Path environment variable of the Visual Studio 2005 Command Prompt so that you can access it easily.
Now that you know where to find wsdl.exe, you can learn more about it by reading the Web Services Description Language Tool (Wsdl.exe) topic.
You are now ready to generate the proxy classes. I like to use the Visual Studio 2005 Command Prompt to access wsdl.exe as it also has the C# compiler in the path. We will use the C# compiler in a bit. In the Visual Studio 2005 Command Prompt, I use the following parameters to generate my proxy classes:
wsdl /language:cs /out:EWS.cs /namespace:ExchangeWebServices https://MyCAServer.Domain.com/ews/services.wsdl
I chose C# as the output language type for my proxy classes. You can also use Visual Basic .NET or C++ proxy classes. EWS.cs is the output code file for my proxy classes. I used ExchangeWebServices for the name of the namespace that holds all the proxy types; this is consistent with the namespace that is used in the Exchange 2007 SDK documentation and the Intellisense files that are included in the downloadable SDK. The last argument is the URL to my Exchange Web Services endpoint.
So now you have a code file with the autogenerated proxies. Next, you compile your code file into an assembly for use in your Exchange Web Services projects. The C# compiler is available with the Visual Studio 2005 Command Prompt. Assuming that you named your code file EWS.cs, you can run the following command at the command prompt to compile your code into an assembly:
csc /target:library /out:EWS.dll EWS.cs
Notice that EWS.dll is the name of the compiled assembly. This is how EWS.dll is created.
Voila! Now you have an assembly that can be reused in all your Exchange Web Service projects. If you currently use the Add Web References option in Visual Studio 2005, I recommend that you start using wsdl.exe instead to generate your Exchange Web Services proxy classes.
As reported on the Microsoft Exchange Team Blog, Service Pack 1 for Exchange Server 2007 has been released! The Microsoft Exchange Server 2007 SP1 SDK is also available online and for download. If you want to find out about the changes for developers in Exchange 2007 SP1, including additions to transport extensibility, Exchange Web Services, and Outlook Web Access customization, check out the What's New in Exchange Server 2007 SP1 Extensibility article.
There's a lot of good stuff in SP1. Go learn. Go develop!