I am very excited to share that Microsoft announced the public beta release of Office 2010, SharePoint Server 2010, Visio 2010, Project 2010, Office Web Apps for business customers, and Office Mobile 2010. If you are developing application based on Outlook; then here are few links related to developing applications for Outlook 2010: What's New for Developers in Outlook 2010 Programming the Outlook 2010 Solutions Module Extending the User Interface in Outlook 2010 If you are looking for resources

A while ago Steve posted information about how to turn of various types of “crawling” in Outlook via named properties that can be set on a store to tell Outlook whether or not it is okay to “crawl” the store in different scenarios.  There are cases where you might have tons of folders in a store and you don’t want Outlook to enumerate all these folders because it would impact performance.  I was recently asked if these properties could be set via a simple VB script.  Turns out it is

If you would like to remove all of the Personal Folders file .PSTs attached to the Outlook Mailbox profile then we can use RemoveStore Method. Here is a sample VBScript to perform the job for us: NOTE: Following programming examples is for illustration only, without warranty either expressed or implied, including, but not limited to, the implied warranties of merchantability and/or fitness for a particular purpose. This sample code assumes that you are familiar with the programming language being

Recently, I was helping someone with a Outlook item leak type issue involving a Task FormRegion.  The symptom was that after opening a task, closing it, and reopening the item they were getting the infamous error message, “COM object that has been separated from its underlying RCW cannot be used.”  They were familiar with some of the issues discussed here and knew to call ReleaseCOMObject() on objects as they were done with them.  However, that is the only part of proper Outlook coding

Misha Shneerson, a senior developer on the VSTO team, has a great post giving us hope in the next version of the .NET framework and the 4.0 CLR.  The feature name Misha uses gives it away, “NOPIA” means no interop assemblies!  …This post is a continuation of my efforts to document common issues I’ve seen when .NET programmers write solutions with Outlook’s object model – be they separate executables, VSTO Add-ins, or Outlook FormRegions. To see all the posts in this series check out my

The only available recurrence patterns to set from OOM are as below: olRecursDaily = 0, olRecursWeekly = 1, olRecursMonthly = 2, olRecursMonthNth = 3, olRecursYearly = 5, and olRecursYearNth = 6. Though we can set every weekday recurrence pattern using UI, Outlook object model does not expose any method to create the pattern as Every Weekday. So, We could use "DayOfWeekMask" to workaround the issue; We found that the mask value is set to 62 on item when we set the recurrence pattern as Every Weekday

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 .

I don't know why we see a lot of customers trying to automate Outlook from a service. It’s pretty well documented that it’s a bad idea. Outlook Object Model (OOM) was written for automating Outlook for a user sitting at the box running it. See, Outlook is very personal and I do mean, it’s very, very personal. Outlook and OOM are as much about being client side as any application with an associated API can be. They will throw-up dialogs for warnings and errors… they will ask you for input based-upon

Plan For What You Can Control One of the common scenarios in OOM programming in managed code that required calling GC.Collect() was handling events.  As has been discussed earlier in this series, item references need to be released before they go out of scope.  This includes items passed into event handlers.  Take the ItemSend event for example... // This leaks 'Item' void app_ItemSend( object Item, ref bool Cancel) { } // This does not leak... void app_ItemSend( object Item, ref bool

Patrick posted a discussion of multithreading with Outlook Object Model and why it doesn't help to make OOM calls on a seperate thread... "Outlook Object Model is run in a STA COM server. This means that all OOM calls are executed on the main thread...You don't gain any performance [when multithreading] 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