Wiz/dumb : Outlook 2007

Line Breaks in Managed Web Service Proxy Classes

Patrick Creehan — Wed, 22 Jul 2009 16:00:00 GMT

Matt, Rick, and I were working on an issue recently where when an application using EWS would set a contact’s Street address to a value containing a carriage return and line feed, like this:

  physicalAddress.Street = "1234 56 Ave NE\r\nc/oPatrick Creehan";

the address card control in Outlook would render it like this:

Ugly, right? The problem was that the XMLSerializer would strip out the line feed and leave the carriage return, which the address card didn’t like.

We could prove by sending raw XML requests in a separate application that sending 
 for the carriage return line feed would make everything right, however, if we set the street address like this:

  physicalAddress.Street = "1234 56 Ave NE&#x0d;&#x0a;c/oPatrick Creehan";

then the contact’s address card would look like this:

Even uglier! It seems that the .net framework, in an attempt to help us out is encoding our string for XML but it wasn’t letting us specify the value we knew was right.

So – the solution is to implement your own class which can handle the XmlSerialization yourself, and replace the auto-generated proxy class’s decision for the type to yours.

Here’s my simple class:

     [SoapTypeAttribute(Namespace = "http://schemas.microsoft.com/exchange/services/2006/types",TypeName="text")]
     public class mstring:IXmlSerializable   
     {
         private string m_string = string.Empty;
 
         public override string ToString()
         {
             return m_string;
         }
         
  
         public static mstring CreateMString(string str){
             mstring newmstring = new mstring();
             newmstring.m_string = str;
             return newmstring;
         }
 
         public static implicit operator mstring(string str)
         {
             return CreateMString(str);
         }
 
 
         #region IXmlSerializable Members
 
         public System.Xml.Schema.XmlSchema GetSchema()
         {
             return new System.Xml.Schema.XmlSchema();
         }
 
         public void ReadXml(XmlReader reader)
         {
             m_string = reader.ReadContentAsString();
         }
 
         public void WriteXml(XmlWriter writer)
         {
             string outString = m_string;
             outString = HttpUtility.HtmlEncode(outString);
 
             outString = outString.Replace("\r", "&#x0d;");
             outString = outString.Replace("\n", "&#x0a;");
 
             writer.WriteRaw(outString.ToString());
         \

A few things to point out is that I decorated this class with the XML namespace for the Exchange Web Services so that it doesn’t fail schema validation. Also, I didn’t really test whether this works when binding to an existing contact – there may be more work needed in the ReadXML section. In order to support still setting the Street property to a string, I had to override the implicit operator. That allows me to set Street to a string even though technically, now Street is an “mstring.” You’ll notice that the work of actually writing the correct value occurs in WriteXml which we got by implementing IXmlSerializable. Now when the SOAP infrastructure goes to build the request, it will call into our interface to serialize this class.

That reminds me, the last thing you need to do to hook all this up is to go into the web service proxy class Reference.cs and modify the PhysicalAddressDictionaryEntryType so the street properties use your new mstring class instead of string:

     /// <remarks/>
     [System.CodeDom.Compiler.GeneratedCodeAttribute("System.Xml", "2.0.50727.4918")]
     [System.SerializableAttribute()]
     [System.Diagnostics.DebuggerStepThroughAttribute()]
     [System.ComponentModel.DesignerCategoryAttribute("code")]
     [System.Xml.Serialization.XmlTypeAttribute(Namespace="http://schemas.microsoft.com/exchange/services/2006/types")]
     public partial class PhysicalAddressDictionaryEntryType {
         
         private mstring streetField;
         
         private string cityField;
         
         private string stateField;
         
         private string countryOrRegionField;
         
         private string postalCodeField;
         
         private PhysicalAddressKeyType keyField;
         
         /// <remarks/>
         public mstring Street {
             get {
                 return this.streetField;
             }
             set {
                 this.streetField = value;
             }
         }
 
         /// <remarks/>
         public string City {
             get {
                 return this.cityField;
             }
             set {
                 this.cityField = value;
             }
         }
         
         /// <remarks/>
         public string State {
             get {
                 return this.stateField;
             }
             set {
                 this.stateField = value;
             }
         }
         
         /// <remarks/>
         public string CountryOrRegion {
             get {
                 return this.countryOrRegionField;
             }
             set {
                 this.countryOrRegionField = value;
             }
         }
         
         /// <remarks/>
         public string PostalCode {
             get {
                 return this.postalCodeField;
             }
             set {
                 this.postalCodeField = value;
             }
         }
         
         /// <remarks/>
         [System.Xml.Serialization.XmlAttributeAttribute()]
         public PhysicalAddressKeyType Key {
             get {
                 return this.keyField;
             }
             set {
                 this.keyField = value;
             }
         }
     \

and (after removing the email address so the address will fit on the card) it looks like this:

Cake.

ConfigureMsgService fails with MAPI_E_INVALID_PARAMETER (0x80070057)

Patrick Creehan — Fri, 10 Jul 2009 16:02:00 GMT

I recently helped a customer with an issue where they were calling ConfigureMsgService and that call was failing, returning an HRESULT of MAPI_E_INVALID_PARAMETER (0x80070057). After debugging it, we established that the reason that ConfigureMsgService was failing was that the PR_PROFILE_HOME_SERVER_ADDRS property was missing from the profile. Outlook seemed to work fine, logons worked, sending mail worked; it was just that ConfigureMsgService would fail. We tried recreating the profile, but still the property wasn’t being set on the profile.

It turns out that PR_PROFILE_HOME_SERVER_ADDRS gets its value from PR_EMS_AB_NETWORK_ADDRESS, which in turn, gets its value from the networkAddress attribute on the server object in Active Directory. That value was set correctly, but permissions to that object were not. After following the requirements laid out on technet for permissions to AD objects, we determined that the Authenticated Users group was missing the ACL for Read All Properties on the server object. Once we set that permission and recreated the profile, the property was set correctly on the profile and ConfigureMsgService started succeeding.

MAPI Docs Moved

Patrick Creehan — Thu, 04 Dec 2008 18:34:00 GMT

So, the Exchange team decided they didn't want to maintain the MAPI documentation anymore since they don't ship MAPI anymore. So the Outlook team stepped up and took over the docs. As such, you can now find them under the Outlook branch in the MSDN left-nav.

http://msdn.microsoft.com/en-us/library/cc765775.aspx

Steve Griffin has been working with the Outlook team on prettying them up and updating them for a few months, and they're now better than ever! He even got a new icon for MFCMAPI out of the deal!

Trouble with Live Search Maps Add-in for Outlook

Patrick Creehan — Wed, 22 Oct 2008 16:08:27 GMT

Several million of you have downloaded the Live Search Maps Add-in for Outlook which allows integration in Outlook with maps and has some cool functionality around extending your appointment blocks to account for automatically calculated travel time among other things.

We have received a large number of support cases that are caused either directly or indirectly because of this add-in. These include hangs, crashes, and leaks. There could be any number of different reasons for those, but to name one culprit, the add-in interops with CDO 1.21, which if you are a messaging developer following the blogs of anyone on our team, you will know that this is not supported.

http://support.microsoft.com/kb/266353

Worse than that, it is distributing CDO.dll, which is also not supported. http://support.microsoft.com/kb/171440

A customer of mine reported an issue that lead us to another discovery. The add-in installs a custom form to your Personal forms registry and changes the default form for the calendar to IPM.Appointment.Location. The form it publishes is based on the LEO.oft form that it installs in your Program Files. The OFT was clearly customized from an existing item in the designer’s mailbox. The form contains a value for PR_START_DATE and PR_END_DATE set to 4/6/2006. The problem with this is that Outlook doesn’t use PR_START_DATE and PR_END_DATE, but CDO 1.21 does and OWA will set them as well. Outlook uses custom named props to keep track of dates. Exchange normally keeps these custom props and PR_START/END_DATE in sync, but only if it needs to because of a modification you did from OWA or something like that. Otherwise, the original values will stick.

If you have a CDO 1.21 application which filters based on a date, all the appointments you created with this form in your calendar will appear to be on 4/6/2006.

The long-term plan for what to do about all the problems in this add-in has not been determined at the time of writing of this blog, but it may result in the download being removed from microsoft.com. This won’t help you fix up any items that already exist in your calendar though – nor will it prevent users from using the add-in if they already have it downloaded and installed.

If you insist on continuing to use the add-in, then please at least use this updated form.

You will need to publish this form to your Personal Forms library over the original. If you uncomfortable with that, you can

Uninstall the add-in using Add/Remove Programs.
Remove the existing form from your Personal forms library,
Close Outlook and ensure no instances of Outlook.exe are running in Task Manager.
Reinstall the add-in,
Replace the LEO.oft in the Program Files folder (C:\Program Files\Live Search Maps for Outlook) with the one contained in the ZIP file linked above.
Open Outlook. (the add-in will publish your new form).

This should allow your CDO 1.21 code to execute normally on any newly created items. For existing items, you can use Outlook Object Model or CDO 1.21 (or Extended MAPI) code to loop through the appointments in your calendar and delete the PR_START_DATE and PR_END_DATE properties if they are on 4/6/2006 with a message class of IPM.Appointment.Location. Outlook should still be able to work with the appointment just fine without those properties.

Misha Shneerson : COM Interop: Handling events has side effects

Patrick Creehan — Wed, 22 Oct 2008 16:04:09 GMT

Misha, a Senior Dev on the VSTO team just posted this blog describing why handling events in managed code can be problematic. This is not news to our team, but he provides a good explanation of why it’s problematic.

Misha Shneerson : COM Interop: Handling events has side effects

If any of what he says sounds familiar, it’s because our own Matt Stehle has been talking about this for a while.

Forwarding Appointments in Outlook Prepopulates “To” Field With All Attendees

Patrick Creehan — Fri, 19 Sep 2008 20:38:00 GMT

We’ve had a lot of folks calling in recently about this one. The symptoms are that if you go to your calendar in Outlook and forward a meeting, the To field is prepopulated with all attendees of the meeting and the Subject field is not prefixed with “FW:.”...(read more)

Form Region Leak in Visual Studio Tools for Office 2008 (v3) Template

Patrick Creehan — Fri, 08 Aug 2008 00:03:24 GMT

I had a case on this a few months ago, but thought more folks might run into this as they start moving to form regions. By default, if you use the VSTO template for creating a form region in Outlook, the item is leaked. This can show up in a number of different symptoms, but the one we saw was that when the item was created (then saved and closed), then modified in WebDav, then they tried to modify the item again in Outlook, the user would get the error:

"The item cannot be saved because it was changed by another user or in a another window."

Fortunately, the resolution is easy, you just need to add a call to Marshal.ReleaseComObject to the FormRegionInitializing event in the designer code.

private void FormRegion1Factory_FormRegionInitializing(object sender, Microsoft.Office.Tools.Outlook.FormRegionInitializingEventArgs e)    
{     
    Marshal.ReleaseComObject(e.OutlookItem);     
}

Two-way STSSync Protocol Server for Outlook 2007

Patrick Creehan — Wed, 11 Jun 2008 00:53:19 GMT

So I've finally done it. I made the first stab at a two-way stssync protocol server. You can get it here:

http://www.codeplex.com/stssyncprovider

I'd love to have some of you start using it and report issues you find with it so I can continue to improve it. I know there are issues already, but it should be mostly there to at least get you started.

This was largely inspired by Stephen Toub's original Custom Calendar Provider sample. I'd recommend reading that article for background on this idea. I later updated it to work with Outlook 2007, but this was still just using the ver=1.0 sync (one-way) . Now, with the release of the SharePoint protocol documents which I announced some months back and troubleshooting logging in Outlook, I've been able to construct a stssync protocol server, which, like Toub's sample, allows for you to simply create a provider that snaps into the engine.

My original design goal was to make it so that provider developers would only have to implement a single interface which returned a dataset of records when Outlook requests them and accepted a dataset of updates when Outlook makes changes and the rest of the plumbing would be handled by the provider engine ("the engine"). I came pretty close. Here is the interface as it stands so far:

public interface IProvider

{

DataSet GetEmptyDataSet(Guid ProviderID);

DataRow GetSingleRow(Guid ProviderID, int id);

DataRow Update(Guid ProviderID, DataRow updateRow);

DataSet GetUpdatesSinceToken(Guid ProviderID, ChangeKey changeKey);

ListType GetProviderType(Guid ProviderID);

StringDictionary GetFieldMappingsForListType(Guid ProviderID, ListType listType);

}

So here's the explanation for the interface.

GetEmptyDataSet: this is mostly used so that the engine can get a feel for what columns are in the table you're returning. You simply return an empty typed dataset or a standard dataset with a single (empty) table that contains the same columns you would later return filled.
GetSingleRow: Pretty easy - I give you an ID, you give me back the row associated with it.
Update: I give you the datarow with changes made and you pass me back the updated row (some columns may change as a result of doing the update - like Modified time, for example)
GetUpdatesSinceToken: I give you a changekey from which you can extract a timestamp, or just call ToString to use the changekey as a watermark for getting changes since the last sync. You return your DataSet filled with any rows that have changed since the provided watermark (changeKey).
GetProviderType: You return a value from the ListType enumeration. This tells the engine whether you're a contacts provider versus a calendar provider, task provider, discussion list provider, or document library provider (no doc library or attachment support is currently in the provider - it's tbi).
GetFieldMappingsForListType - In this method you simply return a StringDictionary filled with any field name mappings the engine can use to map the columns in your dataset to column names it's familiar with. For example, you might do something like oSDict.Add("myContactIDField","ID");

Each method is passed the ProviderID specified in the web.config for this provider. If you want to implement two different providers in the same class, you can distinguish between them using this ID, otherwise, your implementation can largely ignore this parameter - it is mostly used by the engine to get a reference to your interface.

Once you've implemented the interface, just go to the web.config file for the engine and add a new Provider element. Here's a sample:

<ProviderProxy>      
  <Providers>       
    <Provider Name="AdventureWorks Contacts" ID="{7765B84F-6D32-4d31-B28E-6BC615D2F187}" Type="AdventureWorksProvider.Contacts" Assembly="AdventureWorksProvider" />       
  </Providers>       
</ProviderProxy>

Name = just the display name you want to appear on the list in Outlook and on default.aspx
ID = this contains a Guid that is used in invoking methods on your IProvider interface.
Type = the Namespace.ClassName of the type of your IProvider interface.
Assembly = the qualified assembly name of the the assembly that contains the Type specified.

Copy your assembly to the bin directory of the engine web site and the engine will automatically find your assembly. I modified the Pre- and Post-Build events on my AdventureWorks provider sample to automatically do this to simplify the debugging process.

This is just a very rough draft. I wanted to have a sample up there that folks could start to work with and get some ideas. I'd love to hear your feedback and for you to help mold the project into something that is good over time. Please contact me with any issues you find or any suggestions (I know of some myself, already). I'll do my best to put out regular releases as the code base improves. I'd also love to hear what you do with it and what unique stores you start syncing with Outlook.

Just as a note, in this initial release, I do not support one-way sync, just two-way (seems backwards, but the goal was to get a two way sync working).

Also, I may need to change the IProvider interface definition from one release to the next as bugs/feature-completeness dictate probably in the early phases. It doesn't make sense to have an interface that's incomplete. Once I'm able to declare feature-completeness on the IProvider interface, any new enhancements or additional functionality will come in the form of additional/augmented interfaces (IProvider2, etc).

Outlook Requests Can't Get a Date

Patrick Creehan — Wed, 23 Apr 2008 21:52:00 GMT

There exists a scenario in which attendees to a meeting in Outlook will receive an updated meeting request from the originator that appears to be "out-of-date." In the InfoBar, Outlook will display a message that says "This request is out-of-date." If the attendee attempts to accept the meeting request, they get an error dialog box. Now, this is expected if there was an update that was made but a later update was already made - that's sort of what that functionality in Outlook was designed for. However, in this scenario, you see a new meeting request and very shortly after you get an update to the same meeting. It's clear that the update didn't come before the original request, so how can it be out-of-date?

This scenario exists where an appointment is modified by an application using CDO 1.21. In order to get the problematic behavior, the machine running the CDO 1.21 code has to have the clock set to a time earlier than the client machine. If CDO 1.21 modifies the appointment and sends updates within the time delta between the two machines, the update will appear to Outlook to be earlier than the original request.

Imagine the scenario:

CLIENT_MACHINE_1 and CLIENT_MACHINE_2 have a current system time of 3:00 PM.

CDO121_MACHINE has a current system time of 2:57 PM.

3:00 PM	User1 on CLIENT_MACHINE_1 sends a meeting request to User2 on CLIENT_MACHINE_2.
3:01 PM	User2 accepts the meeting request and the appointment is added to User2's calendar.
3:02 PM	CDO 1.21 code runs on CDO121_MACHINE server and modifies the appointment on User1's calendar and sends the meeting request update (stamped 2:59 PM which is the current system time on CDO121_MACHINE) .
3:03 PM	User2 receives the updated meeting request and Outlook displays the update as being out-of-date.

The problem boils down to a difference in meeting update behavior between Outlook and CDO 1.21. There's a sequence number property on meeting requests that Outlook increments each time an update is made to a meeting. Outlook examines this sequence number first when deciding which update is newest - this code was put in place for scenarios like this primarily for pop3 clients, which only use sequence number. The timestamp is used as a secondary factor in deciding which is newer. CDO 1.21 wasn't designed with some of these modern calendaring scenarios in mind and doesn't (and won't ) support incrementing the sequence number - it's simply copied over as are most props.

So...if everyone just synchronizes their clocks to the same time server often enough, we'll all be happy :).

If you have CDO 1.21 code which causes this to occur to some of your clients, here are a few ideas that you can try:

in your processing, don't process meetings that have the timestamp later than the current system time on the machine your code is running on.
Push for your customer to keep machine times in their environments synchronized. This should at least minimize the impact. Clearly this won't account for scenarios where users are using home computers over a VPN or RPC/HTTP connection or using mobile devices that may have clocks synchronized to a different source.

STSSync for the Masses: Toub's Revenge

Patrick Creehan — Tue, 08 Apr 2008 21:13:12 GMT

Many of you have been using the Custom Calendar Provider samples created by Stephen Toub and I:

Stephen Toub - Custom Calendar Providers for Outlook 2003

Custom Calendar Providers for Outlook 2007

The development team has finally documented pretty much everything you need to know in order to build your own STSSync provider (to replace SharePoint as our code samples do). The documentation is included in many of the newly documented Open Protocol specifications:

[MS-OUTSPS] Lists Client Sync Protocol Specification

I'm excited to see what you do with this!

Outlook Crashes When Using Outlook Object Model in Multiple Threads

Patrick Creehan — Thu, 13 Mar 2008 19:11:11 GMT

One of the major requirements most developers are up against these days is ensuring their code runs as fast as possible. No one likes to wait for an application to run, they want seamless, invisible, instant speed. Multithreading is becoming more popular now that many desktops and certainly most servers are shipping with multiple processors or multiple cores. By spinning up multiple threads to execute many different code-paths simultaneously, you can certainly increase the performance of your application.

This mentality is ever-increasingly being blended into Outlook development as well. There has been a rash of developers in recent months who are reporting problems with their Outlook add-ins crashing Outlook when doing multi-threading. While it may give the perception of a better performing add-in, the reality is that this really isn't going to help, nor will it work.

Outlook Object Model is run in a STA COM server. This means that all OOM calls are executed on the main thread. If you are building an add-in that is making OOM calls from another thread (other than the main thread), then your calls need to be properly marshaled back to thread 0. For unmanaged code, you should use CoMarshalInterface or CoMarshalInterThreadInterfaceInStream to marshal your object pointer across threads. This will ensure your OOM calls are properly executed on thread 0. If you are writing managed code, using the OOM through COM interop by means of the PIA will actually handle this marshalling for you.

All of this talk about marshalling interfaces back to the main thread begs the question, "What's the point?" If the OOM calls need to run on thread 0, why spin up a new thread to do OOM work in the first place? That's a great question. You don't gain any performance because all the calls are going to run on the same thread anyway and you incur the overhead hit of doing the marshaling to begin with, so there's not really an advantage to multithreading Outlook Object Model.

Here are some links to some smart folks talking about this same thing:

All Outlook object model calls run on the main thread

Threading in an Outlook Addin

Add-in threading issue causes Outlook to crash or hang

Folder Homepage no longer works in Outlook 2007 from MAPI store providers

Patrick Creehan — Wed, 19 Dec 2007 19:02:00 GMT

If you are developing or have developed a MAPI store provider for use in Outlook and are trying to support folder homepages in your store, you are probably familiar with the PR_FOLDER_WEBVIEWINFO property. This property is undocumented and not supported, but I'll assume for the sake of this article that you have a read/write store and you're allowing Outlook to set that property for you. :)

You may have noticed that folder homepages worked in previous versions of Outlook, but don't work in Outlook 2007. This is because we are turning off folder home pages (FHP) for non-default stores by default in Outlook 2007.

You cannot add a URL to the Address box on the Home Page tab in Outlook 2007 (923933)

Simply setting the registry key below will re-enable them:

\Software\Policies\Microsoft\Office\12.0\Outlook\Security
"NonDefaultStoreScript"=dword:00000001

Tell Us Why You're Still Using ECEs

Patrick Creehan — Wed, 21 Nov 2007 18:06:00 GMT

We want to know why you're still using ECEs as opposed to an add-in. Please hop over to Stephen Griffin's blog and let us know: http://blogs.msdn.com/stephen_griffin/archive/2007/10/12/whither-ece.aspx

Outlook Performance Improvement Patch Released

Patrick Creehan — Tue, 17 Apr 2007 16:12:00 GMT

A new patch was released recently that helps performance on Outlook 2007 noticeably.

Important Information for BCM users:

PLEASE READ THIS ARTICLE BEFORE INSTALLING THE UPDATE: http://support.microsoft.com/kb/935569

Where do I get it:

The Outlook update can be found here: http://www.microsoft.com/downloads/Browse.aspx?DisplayLang=en&nr=20&productId=50663FD1-DBAD-4705-B915-E4CF683E70FE&sortCriteria=date

The BCM patch can be found here: http://www.microsoft.com/downloads/details.aspx?FamilyID=b1fadb55-e4e1-4f67-a69a-3e6bf9b130f0&displaylang=en

KB Article information:

http://support.microsoft.com/kb/933493

http://support.microsoft.com/kb/932086

Custom Calendar Providers for Outlook 2007

Patrick Creehan — Tue, 21 Nov 2006 15:43:00 GMT

So if you were using Stephen Toub's Custom Calendar Provider sample for Outlook 2003, and you are testing out the awesome new Outlook 2007 features, you may have noticed that the code sample he provided doesn't work any more. Stephen is planning to update the article for 2007 eventually, but until then, here's the fix.

The GetList web service method is supposed to return a <Fields> node filled with <Field> nodes that describe each field in that list, including type information, display names, read-only properties, etc. In the sample above, Stephen is not returning the <Fields> node as a part of the response. The reason is that Outlook 2003 ignored this information when it was performing the sync. Outlook 2007 is a little more intelligent in this regard and it does need this information returned. It's not a big deal when linking to a SharePoint Events list, because SharePoint always returns that data. In an effort to keep the code simple, Stephen ignored it.

So the answer is that we need to add that information back in. So what you'll want to do is edit the WssListResponse.cs file as follows:

Add a new private static method called AddFieldElement as follows:


  /// <summary>
  /// Adds a Field node to the Fields parent node
  /// </summary>
  /// <param name="parentDoc">XmlDocument parent doc used for creating the new element</param>
  /// <param name="parentNode">The parent Fields node to which to add the new Field element</param>
  /// <param name="type">Type attribute</param>
  /// <param name="colName">ColName attribute</param>
  /// <param name="name">Name attribute</param>
  /// <param name="displayName">DisplayName attribute</param>
  /// <param name="readOnly">ReadOnly attribute</param>
  /// <param name="hidden">Hidden attribute</param>
  /// <param name="fromBaseType">FromBaseType attribute</param>
  /// <returns></returns>
  private static XmlElement AddFieldElement(XmlDocument parentDoc,XmlNode parentNode,string type, string colName, string name, string displayName,bool readOnly, bool hidden, bool fromBaseType)
  {
   XmlElement fieldEl = parentDoc.CreateElement(null,"Field",_wssns);
   parentNode.AppendChild(fieldEl);
   if(type != null)  AddAttribute(fieldEl,null,"Type",null,type);
   if(colName != null)  AddAttribute(fieldEl,null,"ColName",null,colName);
   if(name != null)  AddAttribute(fieldEl,null,"Name",null,name);
   if(displayName != null) AddAttribute(fieldEl,null,"DisplayName",null,displayName);
   if(readOnly)   AddAttribute(fieldEl,null,"ReadOnly",null,"TRUE");
   if(hidden)    AddAttribute(fieldEl,null,"Hidden",null,"TRUE");
   if(fromBaseType)  AddAttribute(fieldEl,null,"FromBaseType",null,"TRUE");
   return fieldEl;
   
  }

Modify the GetListDescription Method as follows:


  public static XmlNode GetListDescription(string title, Guid id)
  {
   // Create the response document
   XmlDocument doc = new XmlDocument();
   // Add a List element
   XmlNode list = doc.CreateElement(null, "List",  _wssns);
   doc.AppendChild(list);
   // Add attributes about the list to the List element
   AddAttribute(list, null, "DocTemplateUrl", null, "");
   AddAttribute(list, null, "DefaultViewUrl", null, "/Lists/" + id.ToString("N") + "/AllItems.aspx");
   AddAttribute(list, null, "ID", null, id.ToString("B"));
   AddAttribute(list, null, "Title", null, title);
   AddAttribute(list, null, "Description", null, title);
   AddAttribute(list, null, "ImageUrl", null, "/_layouts/images/itevent.gif");
   AddAttribute(list, null, "Name", null, id.ToString("N"));
   AddAttribute(list, null, "BaseType", null, "0");
   AddAttribute(list, null, "ServerTemplate", null, "106");
   AddAttribute(list, null, "Created", null, DateTime.MinValue.AddDays(2).ToString("s").Replace("T", " "));
   AddAttribute(list, null, "Modified", null, DateTime.MinValue.AddDays(3).ToString("s").Replace("T", " "));
   AddAttribute(list, null, "LastDeleted", null, DateTime.MinValue.AddDays(3).ToString("s").Replace("T", " "));
   AddAttribute(list, null, "Version", null, "0");
   AddAttribute(list, null, "Direction", null, "none");
   AddAttribute(list, null, "ThumbnailSize", null, "");
   AddAttribute(list, null, "WebImageWidth", null, "");
   AddAttribute(list, null, "WebImageHeight", null, "");
   AddAttribute(list, null, "Flags", null, "4096");
   AddAttribute(list, null, "ItemCount", null, "1"); // isn't used, so no point in recomputing size of list
   AddAttribute(list, null, "AnonymousPermMask", null, "");
   AddAttribute(list, null, "RootFolder", null, "/Lists/" + id.ToString("N"));
   AddAttribute(list, null, "ReadSecurity", null, "1");
   AddAttribute(list, null, "WriteSecurity", null, "1");
   AddAttribute(list, null, "Author", null, "1");
   AddAttribute(list, null, "AnonymousPermMask", null, "");
   AddAttribute(list, null, "EventSinkAssembly", null, "");
   AddAttribute(list, null, "EventSinkClass", null, "");
   AddAttribute(list, null, "EventSinkData", null, "");
   AddAttribute(list, null, "EmailInsertsFolder", null, "");
   AddAttribute(list, null, "AllowDeletion", null, "TRUE");
   AddAttribute(list, null, "AllowMultiResponses", null, "FALSE");
   AddAttribute(list, null, "EnableAttachments", null, "TRUE");
   AddAttribute(list, null, "EnableModeration", null, "FALSE");
   AddAttribute(list, null, "EnableVersioning", null, "FALSE");
   AddAttribute(list, null, "Hidden", null, "FALSE");
   AddAttribute(list, null, "MultipleDataList", null, "FALSE");
   AddAttribute(list, null, "Ordered", null, "FALSE");
   AddAttribute(list, null, "ShowUser", null, "TRUE");
   //Create Fields node
   XmlElement fieldsNode = doc.CreateElement(null, "Fields",  _wssns);
   list.AppendChild(fieldsNode);
   XmlElement tmpEl;
   //Append Fields
   tmpEl = AddFieldElement(doc,fieldsNode,"Counter","tp_ID","ID","ID",true,false,true);
   tmpEl = AddFieldElement(doc,fieldsNode,"Text","nvarchar1","Title","Title",false,false,true);
   tmpEl = AddFieldElement(doc,fieldsNode,"DateTime","tp_Modified","Modified","Modified",true,false,true);
   AddAttribute(tmpEl,null,"StorageTZ",null,"TRUE");
   tmpEl = AddFieldElement(doc,fieldsNode,"DateTime","tp_Created","Created","Created",true,false,true);
   AddAttribute(tmpEl,null,"StorageTZ",null,"TRUE");
   tmpEl = AddFieldElement(doc,fieldsNode,"User","tp_Author","Author","Created By",true,false,true);
   AddAttribute(tmpEl,null,"List",null,"UserInfo");
   tmpEl = AddFieldElement(doc,fieldsNode,"User","tp_Editor","Editor","Modified By",true,false,true);
   AddAttribute(tmpEl,null,"List",null,"UserInfo");
   tmpEl = AddFieldElement(doc,fieldsNode,"Integer","tp_Version","owshiddenversion","owshiddenversion",true,true,true);
   AddAttribute(tmpEl,null,"SetAs",null,"owshiddenversion");
//   tmpEl = AddFieldElement(doc,fieldsNode,"Attachments","tp_HasAttachment","Attachments","Attachments",true,false,true);
//   tmpEl = AddFieldElement(doc,fieldsNode,"ModStat","tp_ModerationStatus","_ModerationStatus","Approval Status",true,true,true);
//   AddAttribute(tmpEl,null,"CanToggleHidden",null,"TRUE");
//   AddAttribute(tmpEl,null,"Required",null,"FALSE");
//   tmpEl = AddFieldElement(doc,fieldsNode,"Note","ntext1","_ModerationComments","Approver Comments",true,true,true);
//   AddAttribute(tmpEl,null,"CanToggleHidden",null,"TRUE");
//   AddAttribute(tmpEl,null,"Sortable",null,"FALSE");
//   tmpEl = AddFieldElement(doc,fieldsNode,"Computed",null,"Edit","Edit",true,false,true);
//   AddAttribute(tmpEl,null,"Sortable",null,"FALSE");
//   AddAttribute(tmpEl,null,"Filterable",null,"FALSE");
//   AddAttribute(tmpEl,null,"AuthoringInfo",null,"(link to edit item)");
//   tmpEl = AddFieldElement(doc,fieldsNode,"Computed",null,"LinkTitleNoMenu","Title",true,false,true);
//   AddAttribute(tmpEl,null,"AuthoringInfo",null,"(linked to item)");
//   AddAttribute(tmpEl,null,"Dir",null,"");
//   AddAttribute(tmpEl,null,"DisplayNameSrcField",null,"Title");
//   tmpEl = AddFieldElement(doc,fieldsNode,"Computed",null,"LinkTitle","Title",true,false,true);
//   AddAttribute(tmpEl,null,"AuthoringInfo",null,"(linked to item with edit menu)");
//   AddAttribute(tmpEl,null,"DisplayNameSrcField",null,"Title");
//   AddAttribute(tmpEl,null,"ClassInfo",null,"Menu");
//   tmpEl = AddFieldElement(doc,fieldsNode,"Computed",null,"SelectTitle","Select",true,true,true);
//   AddAttribute(tmpEl,null,"AuthoringInfo",null,"(web part connection)");
//   AddAttribute(tmpEl,null,"Dir",null,"");
//   AddAttribute(tmpEl,null,"Sortable",null,"FALSE");
//   AddAttribute(tmpEl,null,"CanToggleHidden",null,"TRUE");
//   tmpEl = AddFieldElement(doc,fieldsNode,"Integer","tp_InstanceID","InstanceID","InstanceID",true,true,true);
//   AddAttribute(tmpEl,null,"Sortable",null,"TRUE");
//   AddAttribute(tmpEl,null,"Filterable",null,"TRUE");
//   AddAttribute(tmpEl,null,"Min",null,"0");
//   AddAttribute(tmpEl,null,"Max",null,"99991231");
//   tmpEl = AddFieldElement(doc,fieldsNode,"Number","tp_ItemOrder","Order","Order",false,true,true);
   tmpEl = AddFieldElement(doc,fieldsNode,"Guid","tp_Guid","GUID","GUID",true,true,true);
   tmpEl = AddFieldElement(doc,fieldsNode,"DateTime","datetime1","EventDate","Begin",false,false,true);
   AddAttribute(tmpEl,null,"Format",null,"DateTime");
   AddAttribute(tmpEl,null,"Sealed",null,"TRUE");
   AddAttribute(tmpEl,null,"Required",null,"TRUE");
   AddAttribute(tmpEl,null,"Filterable",null,"FALSE");
   AddAttribute(tmpEl,null,"FilterableNoRecurrence",null,"TRUE");
   tmpEl = AddFieldElement(doc,fieldsNode,"DateTime","datetime2","EndDate","End",false,false,true);
   AddAttribute(tmpEl,null,"Format",null,"DateTime");
   AddAttribute(tmpEl,null,"Sealed",null,"TRUE");
   AddAttribute(tmpEl,null,"Filterable",null,"FALSE");
   AddAttribute(tmpEl,null,"FilterableNoRecurrence",null,"TRUE");
   tmpEl = AddFieldElement(doc,fieldsNode,"Note","ntext2","Description","Description",false,false,false);
   AddAttribute(tmpEl,null,"Sealed",null,"TRUE");
   AddAttribute(tmpEl,null,"Sortable",null,"False");
   tmpEl = AddFieldElement(doc,fieldsNode,"Text","nvarchar","Location","Location",false,false,false);
   AddAttribute(tmpEl,null,"Sealed",null,"TRUE");
   tmpEl = AddFieldElement(doc,fieldsNode,"Recurrence","bit1","fRecurrence","Recurrence",false,false,false);
   AddAttribute(tmpEl,null,"DisplayImage",null,"recur.gif");
   AddAttribute(tmpEl,null,"HeaderImage",null,"recur.gif");
   AddAttribute(tmpEl,null,"ClassInfo",null,"Icon");
   AddAttribute(tmpEl,null,"Sealed",null,"TRUE");
   AddAttribute(tmpEl,null,"NoEditFormBreak",null,"TRUE");
//   tmpEl = AddFieldElement(doc,fieldsNode,"CrossProjectLink","bit2","WorkspaceLink","Workspace",false,false,false);
//   AddAttribute(tmpEl,null,"Format",null,"EventList");
//   AddAttribute(tmpEl,null,"DisplayImage",null,"mtgicon.gif");
//   AddAttribute(tmpEl,null,"HeaderImage",null,"mtgicnhd.gif");
//   AddAttribute(tmpEl,null,"ClassInfo",null,"Icon");
//   AddAttribute(tmpEl,null,"Title",null,"Meeting Workspace");
//   AddAttribute(tmpEl,null,"Filterable",null,"TRUE");
//   AddAttribute(tmpEl,null,"Sealed",null,"TRUE");
   tmpEl = AddFieldElement(doc,fieldsNode,"Integer","int1","EventType","Event Type",false,true,false);
   AddAttribute(tmpEl,null,"Sealed",null,"TRUE");
   tmpEl = AddFieldElement(doc,fieldsNode,"Guid","uniqueidentifier1","UID","UID",false,true,false);
   AddAttribute(tmpEl,null,"Sealed",null,"TRUE");
   tmpEl = AddFieldElement(doc,fieldsNode,"DateTime","datetime3","RecurrenceID","Recurrence ID",false,true,false);
   AddAttribute(tmpEl,null,"Sealed",null,"TRUE");
   AddAttribute(tmpEl,null,"CalType",null,"1");
   AddAttribute(tmpEl,null,"Format",null,"ISO8601Gregorian");
   tmpEl = AddFieldElement(doc,fieldsNode,"Boolean","bit3","EventCanceled","Event Canceled",false,true,false);
   AddAttribute(tmpEl,null,"Sealed",null,"TRUE");
   tmpEl = AddFieldElement(doc,fieldsNode,"Integer","int2","Duration","Duration",false,true,false);
   AddAttribute(tmpEl,null,"Sealed",null,"TRUE");
   tmpEl = AddFieldElement(doc,fieldsNode,"Note","ntext3","RecurrenceData","RecurrenceData",false,true,false);
   AddAttribute(tmpEl,null,"Sealed",null,"TRUE");
   tmpEl = AddFieldElement(doc,fieldsNode,"Integer","int3","TimeZone","TimeZone",false,true,false);
   AddAttribute(tmpEl,null,"Sealed",null,"TRUE");
   tmpEl = AddFieldElement(doc,fieldsNode,"Note","ntext4","XMLTZone","XMLTZone",false,true,false);
   AddAttribute(tmpEl,null,"Sealed",null,"TRUE");
//   tmpEl = AddFieldElement(doc,fieldsNode,"Integer","int4","MasterSeriesItemID","MasterSeriesItemID",false,true,false);
//   AddAttribute(tmpEl,null,"Sealed",null,"TRUE");
//   tmpEl = AddFieldElement(doc,fieldsNode,"URL","nvarchar3","Workspace","WorkspaceUrl",false,true,false);
//   AddAttribute(tmpEl,null,"Sealed",null,"TRUE");
//   AddAttribute(tmpEl,null,"ColName2",null,"nvarchar4");
   // Return the XML
   return doc;
  }

You'll notice that I have commented out a few lines in this method. There are probably more lines that can be commented out. We're not returning all the information that SharePoint would return, but it's not all useful to Outlook, so why clog the ethernet lines with useless data?!

Anyway, once you've made those modifications, you can recompile the web application and you should be golden!