Deploying a COM Addin in 64-bit Office

Deployment alone is a hassle for VSTO Developers, especially beginners. In this, if one needs to deploy add-in in a 64-bit system is hectic. Here is a simple solution that I have used to debug and deploy add-ins in 64-bit Office.

You just need to follow these steps.
By default, the add-in will be registered with the respective office application. This is enough to run the application in debug mode. If we select ‘my add-in should be available to all users…’ option, it registers the add-in in the 32-bit global registry. This can be seen in RegEdit like this.

But, 64-bit Office cannot see registries in this location. For the add-in to load correctly, the registry keys should be moved to the following location.

For deploying the application…

In Visual Studio 2010, you just need to update the TargetPlatform property to x64 in the Setup Project Properties. Your project is ready to be deployed in 64-bit versions of Office now!

If you are working on Visual Studio 2008, there is a bug in setup project which prevents the add-in from registering 64-bit COM components. A work around is suggested for this problem in Cannot load 64-bit self-registering DLL’s section in Troubleshooting Windows Installer Deployments article in MSDN. It describes how to manually write 64-bit registry keys for making your add-in to work in 64-bit Office.

For more details, go through this article: Deploying COM Add-ins for 64-bit Office using Visual Studio

Saving mail content when a mail is sent from Outlook

To save the content of a mail item when it is sent, here is the procedure.

Private WithEvents itms As Outlook.Items

Private WithEvents SntFldr As Outlook.Folder

SntFldr = Globals.ThisAddIn.Application.Session.GetDefaultFolder(Outlook.OlDefaultFolders.olFolderSentMail)

itms = SntFldr.Items

Private Sub SaveMail() Handles itms.ItemAdd


End Sub

Before, I handled Application.Send Event and checked whether the Item is MailItem or not and then retrieved the content of that. But, with this, we couldn’t get the Date/Time and sending account information. So, opted for the above procedure.

UPDATE: Here is the updated sample code.

Private WithEvents SntFldr As Outlook.Folder
Private WithEvents itms As Outlook.Items
Private Sub ThisAddIn_Startup(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Startup
    SntFldr = Globals.ThisAddIn.Application.Session.GetDefaultFolder(Outlook.OlDefaultFolders.olFolderSentMail)
    itms = SntFldr.Items
End Sub
Private Sub SaveMailAsMsg() Handles itms.ItemAdd
    If TypeOf itms.Item(itms.Count) Is Outlook.MailItem Then
        Dim olMail As Outlook.MailItem = itms.Item(itms.Count)
        MessageBox.Show("Item Added. " & vbCrLf & "Subject: " & olMail.Subject & vbCrLf & "From: " & olMail.SenderEmailAddress)
    End If
End Sub

Hope this helps!


‘inetreStrings’ – liked the nomenclature and the sense of humor of the author of it very much.

String vs string
Lower case string is simply an alias for System.String in the .NET Framework.
== or .Equals
A rule of thumb is that for almost all reference types e.g. objects, use Equals when you want to test equality. == compares whether two references (i.e. object instances) refer to the same object.
Primitive types can be compared for equality using ==, but in the case of strings, the variables on each side of the operators must be of type string.
Have a look at the following code and output, taken from Jon Skeet’s blog.

01    using  System;
03    public class Test
04    {
05    static void Main()
06    {
07    // Create two equal but distinct strings
08    string a = new string(new char[] {'h', 'e', 'l', 'l', 'o'});
09    string b = new string(new char[] {'h', 'e', 'l', 'l', 'o'});
11    Console.WriteLine (a==b);
12    Console.WriteLine (a.Equals(b));
14    // Now let's see what happens with the same tests but
15    // with variables of type object
16    object c = a;
17    object d = b;
19    Console.WriteLine (c==d);
20    Console.WriteLine (c.Equals(d));
21    }
22    }
23    The results are:
25    True
26    True
27    False
28    True

@ before a string
Using @ before a string means the escape sequences are not processed. This making it easier to write fully qualified path names for example.
@”c:DocsSourcea.txt” // rather than “c:\Docs\Source\a.txt”
String objects are immutable, and so editing them, using Replace for example, results in a entirely new string being created, with new memory allocation. The original string is left intact in memory.
The StringBuilder class is designed for situations when one needs to work with a single string and make an arbitrary number of iterative changes to it. New memory allocation is not needed.

Came across the above on Bishop’s Blog while searching about something related to VSTO.

Developing add-ins for multiple versions of Office

Do you want to develop an add-in targeting multiple versions of Office? And you have basic questions like “Is it possible to do? ” and “How to do it?” ? Then you came to the right place. Few months back, I got a requirement to developed add-ins for Outlook 2003 and Outlook 2007. The functionality for both the versions is same. A doubt stroked… when the functionality is same, why would I develop two add-ins separately? Why don’t I make a single build for both the versions of Office?
Then I started searching for techniques to develop add-ins which works in both (2003 and 2007) and read many articles written by VSTO Experts in their blogs, Official VSTO Blog, MSDN, Forums and what not.
Misha Says:

Theoretically, you can develop an add-in for multiple versions of Microsoft Office by catering to the lowest common denominator. This means if you use an Excel 2003 add-in template in Visual Studio 2008, you would be able to develop and debug this with Excel 2007. However if you try this, you may meet these error messages: “You cannot debug or run this project, because the required version of the Microsoft Office application is not installed.”, followed by “Unable to start debugging.”

You can develop Office 2003 add-in in a system where Office 2007 is installed. The following is the procedure that demonstrates how to update your Visual Studio debugging options to use Microsoft Outlook 2007 to debug an add-in targeting Microsoft Outlook 2003.

  1. On the Project menu, click on ProjectName Properties
  2. Click on the Debug tab
  3. In the Start Action pane, click the Start external program radio button
  4. Click the file browser button and navigate to %ProgramFiles%Microsoft OfficeOffice12
  5. Choose Outlook.exe and click Open
  6. Press F5 to debug your add-in

For more details. Go through this article in Misha Shneerson’s Blog.
There are some tips and tricks to be followed and the things that one needs to take care while developing add-ins targeting multiple versions of Office in Andrew’s Blog. Have a look at this too. You might find it interesting and useful.
Here is an MSDN article on Running Solutions in Different Versions of Microsoft Office
Hope this helps!

Awesome article on VSTO

Just came across an awesome article on ‘Visual Studio Tools for Office‘ written by Craig Bailey in his blog Its a brief story of VSTO narrated in simple words so that even beginners can understand it.
The post is written in interactive manner covering useful points like

  • What is VSTO?
  • Why VSTO?
  • How to start working with VSTO?
  • Some misconceptions on VSTO
  • Hurdles with VSTO

I am very much impressed with the article and would recommend this to VSTO entrants and enthusiasts to get a clear view of it. Hope you too will like it!
By the way, where is the link?
Here is it… 🙂

VBA Vs VSTO – An interesting study

I started developing add-ins with VSTO 2005 SE and have developed my first add-in for Outlook 2003. Our old add-ins are developed using VBA. Now, my job is to add extra functionality and enhancements to it. For doing this, I have chosen VSTO for doing this project and planned to redesign it. After informing this to my TL and started the project, Some one asked me – What is the difference between VBA and VSTO? Why did you choose VSTO for developing the add-in? 

VB veterans or Microsoft Office advanced users should know VBA. It’s the only way you can do some automations or customizations to Microsoft Office products, well at least until 2004. Along came Visual Studio Tools for Office (VSTO) v1 at 2004, introduced another option for doing stuffs like VBA did. 

Just came across an article on the same in  Andri’s Blog which tryies to answer many common questions about VBA and VSTO. I would like to share it with you. You can find the original post here.  

1. Leverage .NET Framework 

The most fundamental difference between VSTO and VBA is that VSTO based on Microsoft .NET Framework. All .NET developer should know the advantages that .NET framework offers. It includes a large library that cover a large range of programming needs in a number of areas. As part of .NET technology, VSTO inherits that richness. At the very basic level, VSTO has access to .NET Base Class Library (BCL) that includes basic functionality, including Collection, Input Output (IO), Globalization, etc. VSTO also has access to some .NET Framework Class Libraries (FCL), such as XML processing, ADO.NET, LINQ, Windows Forms, WCF, etc. 

The rest of the list are the consequence of this point. If you don’t have time to read, you can stop here 🙂 

2. Development Productivity 

Despite I’m a coder and my passion about technologies, at the end I’m also an businessman. When it come to business, productivity must be taken into account. Mostly, productivity is all about tool. 

Why on earth using VSTO is more productive that VBA? Well, as its name, developing using VSTO means using world-class IDE, Visual Studio. Compare it to VBA Editor within Microsoft Excel or Word, I think it’s just not fair to compare them. More over, Visual Studio seems will be more and more improved by Microsoft in the future, while VBA Editor is not. I’ll talk more about productivity as I go along with this list. 

3. Language features 

Since VSTO is based on .NET framework, it has access to all .NET language features. As we know, coding using .NET means coding using .NET compatible languages, such as VB.NET and C#. Unlike VBA that should be coded using Visual Basic language (which is a procedural language), coding VSTO allows us to code using VB.NET or C# (which are pure Object-oriented Programming language). 

I won’t tell much about OOP advantages compared to procedural language here. Some points I’d like to highlight here are reusability and error/exception handling. As we know, OOP language allows us to achieve reusability through its features, including: inheritance, polymorphism, abstract classes, and interfaces. VBA is failed to perform those stuffs (at least not pure) so it’s quite hard to achieve reusability. In term of error handling, VB.NET and C# also have language construct called try…catch…finally that makes a nice, elegant way to prove your code’s infallibility. In VBA, error handling is performed using GoSub, GoTo, or On Error statement, that will lead to frustration as your code grows. 

The latest VB.NET 9.0 and C# 3.0 features are accessible from VSTO, including: Automatically Implemented Properties, Implicitly Typed Local Variables, Extension Methods, Lambda Expressions, Object Initializers, Collection Initializers, Anonymous Types, and Query Expressions. All those new features are the basis of the great technology like Languange-integrated Query (LINQ), that adds SQL-like query capabilities to .NET language for querying array, collection, XML, and RDBMS. 

4. Application level hooks 

VSTO can access many application level functionality, such as Ribbon, Custom Task Panes, etc. Using VSTO, you can develop application level add-in that will always be available regardless opened document. By contrast, VBA customization is document level. 

5. Customization Code Separation 

Unlike VBA, where customization code is stored in the documents file themselves, code written for VSTO are compiled and store in separate .NET Assembly which is associated with the documents by means of custom properties. At runtime, that assembly is loaded on the fly. This separation allows us to easily maintain the customization and apply security constraints (I talk more about this later). 

6. UI Customization 

When it comes to user interface, VSTO provides more complete functionality compared to VBA. VSTO allows us to customize Task Panes that is impossible in VBA. Task Pane is an specialized pane, typically shown on the left, introduced in Office 2003 that can display additional controls or functionality you can do on document. You can drag and drop all Windows Forms controls into Task Panes and use them as you can do in Windows Forms development. You can also use Data-bound controls and Data Sources to easily bind data from DBMS into Task Panes. If you have controls built using Windows Presentation Foundation (WPF) technology, you can host them on Task Panes. All you can do on Task Panes, can also be done on Outlook Form Region, which is a custom form developed to extend Outlook UI. 

It’s also easy to customize Ribbon, an UI element introduced in Office 2007. You can use VBA to customize the Ribbon using RibbonX, but VSTO makes it even easier by providing a Ribbon designer that makes adding new tabs, groups, and controls to the Ribbon as intuitive as adding a control to a Windows Form. 

7. Source control 

Like any .NET projects, you can use Source Control server like Team Foundation Server (TFS) to facilitate collaborative development for VSTO-based project. All VSTO project artifacts can be checked in/out to/from TFS server, including Office document (xls, xlsx, doc, docx, etc). As far as I know, there’s still no add-in or provider in Excel or Word to control VBA project source code using TFS. However, there does exist some add-in for
Access/Excel to work with Source Safe to version control the VBA project. For example, here’s the add-in for Access 2003: 

8. Distributed System 

When it’s first introduced, one of .NET buzzwords is XML Web Services. It introduced the very easy way to develop web services-based application, more generally, service-oriented or distributed application. .NET also introduced Remoting for more native way to implement Remote Procedure Call (RPC). Start from .NET 3.0, all those technologies now converge into one technology called Windows Communication Foundation (WCF). 

Since VSTO is a part of .NET, it inherits all cool technologies like WCF. In other words, it’s easy to develop VSTO Add-In to access XML Web Services, for example. It’s same as like you do when you access XML Web Services from ASP.NET or Windows Forms, just Add Web Reference (or Add Service in VS 2008) to create proxy classes, and use those classes. And all that functionality is built-in. Compare to VBA that you need certain add-on to be able to access Web Services. You can read more about Calling XML Web Services from VBA

9. Deployment 

No matter how well an application runs while it’s on development, deployment can be an issue. Deployment is not only about installation on users’ computer, it’s also about patching, version update, and maintainability. Since VBA application is embedded in the document itself, it’s easy to install the application on users’ computer by only copying the document. But when it comes to update the code, you have to open the document and change the code manually. Just imagine how that can be done for many users environment. 

On the other hand, as the nature of VSTO, the customization code is stored separately in .NET assembly (*.dll file) that actually linked to the document (for document-level customization) or Office application (for application-level customization). That .NET assembly can be deployed to a central location and all the documents just link to it, that will make updating quite easy. Updating can be configured so it can be checked every time the document is opened, or by specific period (7 days, one month, etc). 

Furthermore, VSTO supports two deployment models 

Also refer to this blog about VSTO v3 Deployment Session

10. Security 

Lets face it, it’s difficult to trust VBA code, as evidenced by the high number of VBA macro viruses those have been developed. In VBA, there are three basic security options: 

  • Set the security settings to high on user machines and digitally sign your code.
  • Let the user decide whether or not to trust the code when presented with the macro virus warning.
  • Set the security to low to allow all code to run (including malicious code). Note that this third option should never be used

Those security options must be selected and configured by user manually. 

Lets compare to VSTO security model. The VSTO security model involves several technologies: the Visual Studio Tools for Office runtime, ClickOnce, the Trust Center in Microsoft Office, and the Internet Explorer restricted sites zone. During installation, here is the sequence of security check (taken from MSDN Documentation). 


Microsoft Office Security Checks
Microsoft Office Security Checks

Runtime and ClickOnce Security Checks
Runtime and ClickOnce Security Checks

Runtime inclusion list checks
Runtime inclusion list checks

If you still don’t trust it, then you’re so paranoid 🙂 

I think the comparison list is enough for now. But there’s possibility that the list will grow as the VSTO will be improved more and more along with .NET update. Currently, VSTO is version 3 or VSTO v3. I assume there’re will be v4, v5, etc, following the new release of .NET framework. On the other hand, VBA will no longer be improved, although there’s still no plan from Microsoft to retire it. 

By this post, I’m not trying to make a war between VBA and VSTO. It’s just a matter of choice. When it comes to choice, it’s fair to compare them. Actually, VBA and VSTO can become friend. Many blog posts and articles those talk about interoperability between those two, for example: Extending VBA with VSTO 3.0. The interoperability is only possible by using VSTO v3. 

That’s all!

VSTO in Visual Studio 2010

I am just trying to put my hands into VSTO in VS 2010. This is just an overview of that based on Saurabh Bhatia`s PDC Presentation. Some important points are briefly discussed in this post. Have a look.
One of the biggest hurdles with VSTO is deployment.
As you probably know, the pre-requisites for running a VSTO app (even of the simplest Hello World variety) include:

  • .NET Framework 3.5
  • Primary Interop Assemblies (PIAs)
  • VSTO Runtime
  • (Plus Office of course)

Now, packaging these isn’t the issue, since the Visual Studio team have worked hard to make the ClickOnce process a simple and seamless experience. The issue is the size of the download, plus requiring Admin privileges on the box you are installing on. For developers like you and me this doesn’t sound like much of a problem, but for an IT Manager in charge of rolling a simple VSTO app out across an enterprise this can be a significant headache (although Group policy can solve some of this).
And it doesn’t stop there, because if you have a number of VSTO add-ins going out, each of them needs to be installed separately. Finally there’s limitations with how to control post-install events (Eg copying Word or Excel templates into the proper locations).
The VSTO team have been focusing on deployment and security issues over the last 2 releases, and in the VS2008 release they made significant improvements. The recent SP1 for .NET 3.5 further eased the process.
But, it’s a process that still needs improvement.
Visual Studio 2010Visual Studio 2010
So, it’s good to see that the team are making excellent progress in VS2010. As the recent PDC presentation from Saurabh Bhatia demonstrated (PowerPoint file here), there’s already key functionality increases.
[UPDATE: Removed the embedded presentation as it was preloading and sucking bandwidth – click here to view]
The main points covered are:

  • Multi-project deployment (eg install an Outlook add-in, Excel add-in and Word add-in all at once)
  • Post deployment custom actions (eg moving files to user directories, deleting files during uninstall)
  • No-PIA installs (no need to include the PIAs – achieved via Type Embedding – a feature in CLR 4.0

This is welcome news to VSTO developers (actually probably more so for IT Managers). The pre-requisites are now down to the .NET Framework and the VSTO Runtime, and complex VSTO applications can be installed with a single install and enabled to configure itself.
It’d be so much simpler if the VSTO Runtime was automatically installed with Office or the Framework, but as we know, Microsoft are trying to reduce install sizes these days not add to them. Deployment will always have its pain points – good to see the team are getting close to an acceptable compromise.

Extended Online Support for VSTO Developers

Happy to tell you that Microsoft has recently revamped the VSTO online learning center. The site provides information and knowledge about VSTO and how to use it to develop Excel, Word and Outlook solutions and also how to deploy the solutions. From my point of view it’s welcoming as I know that many developers are interested in VSTO but lack the basic information and knowledge about VSTO. Considerably, there are very less resources on VSTO on the Internet too. Hope this helps the programmers who are enthusiastic to work with VSTO.
The startpage is available at Office Development with Visual Studio.
The Excel section can be accessed directly via Outlook Solutions with Visual Studio
Perhaps these pages can make VSTO more understandable (and also get a better reputation) in the Excel Development Community? After all, knowledge is the key to all new areas.