In this post I will give an introduction to COM Interop and covering some of the basic concepts you need to understand when dealing with VSTO and the Office Object Model. By understanding the way COM interop works and the potential impact of not deterministically cleaning up your references you will build much more reliable VSTO add-ins.
After covering the basics of COM Interop I will write about a helper library I have written and have code examples of how it can make your life much easier.
Without a good project structure you will find you cannot test any of your code and will possibly run into maintainability problems. For my user group talk last month I built a Outlook add-in that synchronises contacts and events from Facebook into outlook. I chose Facebook because it has a easy to access public API and most people are familiar with it. Over the next few weeks I will go through the process of building it, demonstrating many concepts as I go. At the end I will release the completed project.
If we want to do anything interesting with VSTO and Outlook we will have to access data from Outlook. That will normally be Contacts, or Appointments or Emails? When you do this you will probably leak items, then Outlook will stop behaving normally, you can get ghost inspectors (click save & close, and the window stays open, but ribbon is grayed out), or errors when you try to edit a item through the Outlook UI. There can be many side effects, most are not fun to track down the cause.
A really common problem I see with VSTO is getting access to dependencies. Because the framework builds your ribbons and the main point of interaction is in the Load event, developers resort to putting dependencies in their ThisAddin.cs class, then access them through Globals.ThisAddin.MyDependency.
This is bad..
Unfortunately out of the box this is really hard to get around, in this post I will present a few options and a few helper classes that will be included in Outlook.Utility very soon.
I try to use IoC and DI as much as I can inside Outlook add-ins, in some places this is really hard, so I fall back to a ServiceLocator.
Its been a while since I have blogged, since starting with VSTO I haven’t posted much. That is about to change.
I have been playing around with VSTO a lot lately, mainly Outlook but I will move into Word and Excel very soon because I see a lot of business value in the VSTO platform.
I have started an open source library called Outlook.Utility, which I will probably break into Office.Utility as well to separate Office and Outlook functionality. There is a very good but old article on MSDN (http://msdn.microsoft.com/en-us/library/aa479345.aspx). In the code example in that article they have a Outlook.Utility project which has some really handy classes in it. I have cleaned up and enhanced a few of the classes, as well as adding my own.
The main issue with the code is it doesn’t release any COM references and actually leaks, as I invest more time into my Outlook.Utility project I will clean up all the leaks as well as add my own helper classes and extensions. I am going to start a Enterprise VSTO series that will use this library and cover ways you can create a good maintainable add-in.
Over a few posts I will cover IoC, Patterns to use, COM interop, performance issues/solutions, WPF integration (using MVVM) and a few other things. I then will probably put it all in a webcast at the end.
Many of the apps I have written need to target multiple databases or I want the connection to be configurable by the user. I have a user control in my common library that I use all the time to let the user connect to a database.
You will need the Sql Management Objects from http://www.microsoft.com/Downloads/details.aspx?familyid=B33D2C78-1059-4CE2-B80D-2343C099BCB4&displaylang=en to compile the demo project.
Features:
All in all, for small apps I think this makes connecting to a SQL database really easy! The SqlConnectionString class is also handy for any type of apps that have to manipulate a Sql Connection String.
I decided today that I wanted a quake style powershell console (with the classic win+` to activate or hide), and here is the end result:
I used http://www.instructables.com/id/“Drop-Down”,-Quake-style-command-prompt-for-Window/ as a template to get it all working, but wanted to use Console2 instead of v1.5 like this article uses.
I have been trying to get a ClickOnce VSTO add-in publishing automatically during a build and do not want visual studio on my build server.
This blog post was very useful for getting the initial build working http://abdullin.com/journal/2009/2/17/building-vsto-solutions-without-visual-studio.html it also mentions how to fix the error MSB3147: Could not find required file ‘setup.bin’ in ‘ProjectFolder\Engine’ error I was getting.
According to the post we just have to copy the Generic Bootstrapper across to our build machine and create a registry key to let .net know where to find it.
What all the resources (I have seen the same fix posted in a lot of places) fail to mention is the registry key that you need to modify if you are running a x64 system is HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\GenericBootstrapper\3.5.
This Wow6432Node key has got me a few times before…
A few of my apps require opening the same window for a lot of different items and I wanted each WPF window to remember its size, position and state all the time. Nothing annoys me more than closing a window, opening the same window and its back on my second monitor.
So I went in search of a solution that someone else had written first, I found a example on the MSDN website.What makes this sample good is it makes use of the Win32 API’s, specifically GetWindowPlacement and SetWindowPlacement in User32.dll. Because of this our code doesn’t have to worry about missing second monitors, reduced resolution and other edge cases that can cause the normal headaches.
The second example I found has the idea of using attached properties, which I liked a lot.
The problem with the MSDN sample is you need to set up each window manually by overriding some of the Windows methods, the second solution did not cater for the edge cases.
Talking to Jeremy Thake last night at the Perth SDDN meeting for the month he suggested I really should get a blog and start sharing some of my experiences while developing. It has been on my To do list for a long time now so I decided to get it done!
I have been working at a company called ioGlobal for about 18 months now and have been doing a lot of internal development. The great thing about my role at the moment is I am doing a lot of the IT pro side of things, but spend most of my time developing all the software we need internally. Being the only staff member with .net experience I have been able to choose my own technologies and run my own projects.
I will be talking about nifty programs I have found and ways I have solved problems that I have come across while writing a lot of these small apps. There are a few apps in particular that I think are quite interesting and I had a lot of trouble finding any information on the net about them.