Answered by:

How to access Exchange Public folders programatically - C#

Question

I need a routine that will obtain a count of items in a given Exchange Public Folder. I'm not worried about how to write the code as much as the restrictions a C# routine would have. Are there any?

In other words, I already have a routine that gets the directory statistics such number of folders or files.... But when it comes to Public Folders located in Exchange, how do I identify the folder path?

Answers

The best I can recommend, really, is that you follow the instructions provided in the MSDN article for adding the web references. "Web Services On The Local Machine" is not what you want to do.

You will need to know the fully qualified name of your exchange server, there is no way around it. This is true for adding the web reference, but it's also true when actually writing code against EWS. Have you setup the Exchange server yourself? If you have, then you are probably the one who knows what the server name is. Otherwise, you will probably want to ask your administrator.

When you use "Microsoft.Office.Outlook.Interop", you are using the Outlook Object Model, which means your application will only work on computers on which Outlook is installed. The Outlook Object Model, even if you are still using a version of Outlook prior to 2007, should work just fine against Exchange 2007.

I still recommend you use EWS. Adding the web reference is very easy as long as you know your server name or the public facing URL of EWS in case you are developing from outside your company's internal network (again, ask your administrator).

All replies

Exchange Public Folders are not file system folders. You cannot access them using file system specific routines; they don't have a physical path.

To access Exchange Public Folders, I recommend you use Exchange Web Services. You can retrieve the Public Folder hierarchy using the FindFolder method and access items in the Public Folders using the FindItem method.

To use Exchange Web Services in your C# application, you will probably want to use the "Add Web Reference" feature of Visual Studio 2005 (or "Add Service Reference" feature of Visual Studio 2008) to generate proxy classes that handle the communication with Exchange Web Services. This article describes how to use the "Add Web Reference" feature in VS 2005.

Appreciate the help. I took a look at the code for the FindFolder operation. You wouldn't happen to know how the C# calls the code provided in their example? I don't understand why if the Language Filter for that web site is set to C# the code provided ends up in xml:

Could you drop a few lines of code to demonstrate how my C# application would use the code above? Another thing I wonder about is the Exchange server access approach. I guess the code above assumes you have already gained access to the server ... I'm not that far along yet.

It just seems odd to me that for the example you provided (a good one) the code makes no mention of gaining access to the server.

I need help on the theory of this stuff ! What exactly do you mean by proxy classes? Does the use of a 'proxy' somehow over-ride the necessity for code which makes a request for access to the server?

When I use Outlook I can clearly see the Public Folders available through the directory. I can see these because I have logged on to Exchange. How then could any application see these folders without a login?

Although there is a lot of code at the link you pointed me to, can you narrow down my search if you happend to know what I need here?

Once again, are you saying the 'FindFolder' example you pointed me to in your last post is all sufficient?? If so, I don't get it.

// Define the properties to be returned in the response. FolderResponseShapeType responseShape = new FolderResponseShapeType(); responseShape.BaseShape = DefaultShapeNamesType.Default; findFolderRequest.FolderShape = responseShape;

You do need to log into the Exchange server. Here is the base of the code you need to write to do what you want. I think that adding a web reference is already well covered on MSDN, so thie below will assume that you have do it. Let me know if you need additional information.

2) Type the URL of the wsdl file that describes the location of the Client Access server that hosts Exchange Web Services; for example, https://myClientAccessServer.myDomain.com/EWS/Services.wsdl, where myClientAccessServer.myDomain.com is the fully qualified domain name (FQDN) of the Client Access server.

What happens for me is that I get the same dialogue shown in the example and I am forced to choose this option because the other two don't produce anything:

Web Services On the Local Machine

When I click this link to perform analysis on my machine the one result that seems to work for me is:

I then select this option to as my URL for the Client Access server but I get this error:

localhost/ReportServer - /

In short, my current application is using 'Microsoft.Office.Interop.Outlook' to do all mail transactions. However, the new feature that I'm trying to add will support operations with Exchange 2007 and that is good. Why? Because we have recently migrated from 2003 to 2007.

As the new developer here - I'm not quite sure how the application survives doing current email notification since apparently we have made the switch to 2007. Do you happen to know whether 'Microsoft.Office.Interop.Outlook' classes supports 2007?

The best I can recommend, really, is that you follow the instructions provided in the MSDN article for adding the web references. "Web Services On The Local Machine" is not what you want to do.

You will need to know the fully qualified name of your exchange server, there is no way around it. This is true for adding the web reference, but it's also true when actually writing code against EWS. Have you setup the Exchange server yourself? If you have, then you are probably the one who knows what the server name is. Otherwise, you will probably want to ask your administrator.

When you use "Microsoft.Office.Outlook.Interop", you are using the Outlook Object Model, which means your application will only work on computers on which Outlook is installed. The Outlook Object Model, even if you are still using a version of Outlook prior to 2007, should work just fine against Exchange 2007.

I still recommend you use EWS. Adding the web reference is very easy as long as you know your server name or the public facing URL of EWS in case you are developing from outside your company's internal network (again, ask your administrator).

Microsoft is conducting an online survey to understand your opinion of the Technet Web site. If you choose to participate, the online survey will be presented to you when you leave the Technet Web site.