Talking with Exchange Server

The usual requirements of talking with outlook can be handled by the rather extensive object model which outlook provides. Now, if you want to interact with outlook from a server based application (say ASP.NET or a remoting host), using object model might not be the right solution since you need outlook client installed, you might have to configure individual profiles etc. A better approach could be talk directly to the exchange server.

To talk with Exchange, the following approaches seems available (be-ware; even after you select you preferredAPI and talking channel, you could easily get lost in the n versions of the library one for each of the outlook versions.) :

1.) CDO-EX objects:
Of the various versions of CDO, the version for exchange - CDOEX could be used to manage components in the exchange server. The only issue here being that the application consuming CDOEX needs to be on the same machine as that of the server. CDO 1.2.1 does seem to let you access exchange servers remotely but could not get it to install on a machine without outlook 2007 :(

Note that as of Outlook 2007, it appears CDO is being provided as a separate download.

2.) WebDAV
The slowest of the lot and the most difficult to understand, uses plain http requests in an xml format to perform each action. The convenience (you can use it remotely too) of using this method usually outweighs the speed and the learning curve.

WebDAV notifications using HTTPU is interesting in that you get notifications from the remote server via UDP message. A simple explanation with example is available at infinitec.de

3.) Exchange OLE DB
An OLE Db provider for exchange sounds like the best possible way to talk with exchange server. Sadly, your happiness ends when msdn tells you that the application consuming this driver needs to be on the same server as that of the exchange. Err!

Effectively, if performance is your main concern, your preference should be to go for CDO/OleDB/WebDav (in that order). Perhaps the future release of the Exchange API/SDK might contain a Microsoft.Exchange.Server.Core assembly to talk directly and easily.

Shall talk about using WebDAV within a C# application in detail in one of the upcoming posts.

SSW Code Auditor - a review

A quick search for code standards review tools for C# lead me to SSW Code Auditor. Among others (FxCop, Standards Master 2005,FMS Total..), this tool appeared to be something easy for an average developer to use from the first day.

Details

Once the trial version is downloaded, the first thing which would strike you are the pictures of all kinds of fruits (yes! apple, the sign of health to start with). The GUI tries to be very straightforward using a wizard kind of interface but is not effective. It would take atleast another 10mins before you realise that the 'database' is effectively a kind of project where you add each subsections to be tested, as 'jobs'. Not sure why this isnt just a project file and a list of jobs within it such that I can create multiple projects using File->New?

Anyways, once you add your list of folders, files which needs to be audited, you get to select the rules you want to be tested. The trial version appears to have 147 rules of all kinds enabled. Perhaps new standard rules would be added periodically by SSW as a rule-update file?

Could not add a new rule or edit a rule in this trial version. But would have been good if the trial version let you create one custom rule - just to check out things. A fully functional version which works for particular time period is recommended for bringing out trial versions of utils.

Within a normal wizard layout, the usual tendency is to click next next next.. finish. One non-standard UI design was the start/skip button within one of the wizard page. These buttons are the ones which check the selected files against the selected rules. What would have been a better UI design would be to bring down the start/stop/skip buttons instead of the back/next/cancel buttons.

The browser rendered result page tells if the application is healthy or not (images varying from apple to burger to denote these!) and the detailed list of issues it located. Thankfully, the results can be arranged by file names such that I can see all the issues my particular class has.

What strikes you while you use this application is the language of the messages contained in the forms and the reports. Its just simple and communicates good to the developer. The report tells you what is wrong in plain simple English with a quick tip. Great, when you think about the rather complex messages from FxCop.

The other nifty functions included emailing the results, scheduling the tests (again not available in trial version), creating a batch file which you could execute from the command line and also performing a test of the just checked-in file ( with Team Foundation Server). This feature would be really good - the developer would get the list of issues with his file as soon as its checked in - great.

In addition to the standalone application, the VS.NET plugin is what you would use on a daily basis. The plugin makes the distinction between FxCop and Code Auditor obvious when it lets you select assemblies with FxCop and source code with itself. Sadly, I could not get this to test just my active source file. It had to perform the test on the whole project each time.

The VS.NET plugin also appears to add two files (one for fxcop another for itself) into an individual solution item folder for each of the project in the solution. This definitely appears to clutter up the solution explorer. What would have been a lot better is a single solution item with all the files for all the project within the active solution.

To summarise, once you get a kick of this no-nonsense tool, it should be a pretty good companion during your daily development activity. Perhaps the next versions might also fix the obvious errors automatically.

All those fruits; from apples, bananas to strawberry has definitely made me hungry! I think am off to the kitchen.