- Microsoft office 2007 primary interop assemblies how to#
- Microsoft office 2007 primary interop assemblies code#
A variation of this scenario occurs when your add-in supporting, say, Outlook 2007 and higher is loaded by Outlook 2000, 2002, or 2003. In that situation, you can check the ADXAddin.HostVersion property before calling such a method. If it isn’t possible to modify the algorithm, the workaround is to use the interop assembly providing early binding information for such a call.īut this workaround produces another problem shown in the figure below: In Outlook, you can use Extended MAPI to scan MailItems and their attachments in a given folder. Say, instead of getting/setting the values of many Excel cells one-by-one, you can get/set an array of values by calling Range.Value for a Range object covering the cells.
Microsoft office 2007 primary interop assemblies code#
Sometimes there are ways to speed up your code by using other algorithms. It does matter however if you do a late-binding call many times, say, in a nested loop. In a typical add-in, this problem is not critical, and does not matter much. This is because the method you are calling to must be found in the type library first. More specifically, a late binding call might be many times slower than the early binding call. Don’t know if similar problem exist for late binding calls.Īnother problem with late binding calls is that they are relatively slow. Say, calling Outlook.ActiveWindow via early binding led to a problem with entering VBA code in the VBA IDE of Outlook 2003, late binding did not raise such a problem. On a rare occasion, you may run into different behavior demonstrated by the object model of the host application for early and late binding calls. Whether this approach is useful or not, this is you who decides. Then you can replace the interop assemblies referenced by your project with the interop for a previous version of the application and reiterate the procedure. When this is done, you can replace early-binding calls to the features introduced in this Office version with late binding calls and make sure these calls work. There is an approach that lets you diminish that time: you can start developing your add-in using interops for the highest version of the Office application. In addition, the late-binding call requires more time to debug. Therefore it takes more time to write it. First off, because the compiler doesn't have information about the method (property) called, it doesn’t help you costruct such a call. There are several issues with late binding calls. For instance, see Get Outlook profile name programatically. There’s a lot of code samples demonstrating the use of this method on our forums. NET, you use the method to access a method via late binding. This approach is illustrated in the figure below: In such a situation you need to use late binding. It’s quite natural, however, as the Outlook 2003 interop doesn’t contain early-binding information for things introduced later, in Outlook 2007 or Outlook 2010. Because versions of an Office application are almost 100% backward compatible, the oldest application version supported by your add-in is often thought of as the least common multiple.Ī typical problem with this approach is demonstrated by the figure below:įor instance, the situation above occurs when you use an Outlook 2003 interop and you need to program features introduced in Outlook 2007 or Outlook 2010. When developing an Office COM add-in supporting several versions of an Office application, the typical approach is to use the interop for the oldest Office version supported by your add-in. But see NOTA BENE at the end of this post. When developing an Office add-in that supports only one Office version, an easy and straightforward way is to choose the interop for that Office version. NET provides version-neutral interops that are interops for Office 2000 applications. These interops are called Primary Interop Assemblies or PIAs. Microsoft provides interops for all Office applications starting from Office version 2002. NET assembly providing meta-information about objects, properties, methods, and parameters available in the type library (=object model) of the Office application. An interop for an Office application is a. NET via early binding you need to use a corresponding interop.
Microsoft office 2007 primary interop assemblies how to#