Ok. after a bit of research I understand (I think) now why you're taking a while to get the new version out.
For those interested, see more specifics about developing add-ins for Office 2010 x32 and x64 at
http://blogs.msdn.com/officedevdocs/archive/2009/11/25/developing-outlook-2010-solutions-for-32-bit-and-64-bit-systems.aspx.
Here are the relevant bits:
- Code: Select all
Managed Add-ins, and Unmanaged Applications and Add-ins for Outlook
Basically, the way to call the Outlook object model remains the same*, regardless of whether the add-ins are going to be run on a 32-bit or 64-bit version of Outlook 2010.
You do not need to recompile existing (32-bit) managed or unmanaged add-ins, if you expect the add-ins to continue to run only on computers with 32-bit Outlook installed.
In particular, for existing managed add-ins, make sure that you have built them using Microsoft Visual Studio Tools for the Microsoft Office system 3.0, or Microsoft Office development tools in Visual Studio 2010, with the Any CPU option for target platform on the Build tab of the Project Properties dialog box. Add-ins built with such settings work for (both 32-bit and) 64-bit versions of Office 2010. If you used other settings, rebuild your managed add-ins using the specified settings so that they will run on computers with either 32-bit or 64-bit Outlook 2010 installed.
Any existing unmanaged, standalone application (in .exe) that runs outside of the Outlook process written for 32-bit Outlook does not require recompilation for 64-bit Outlook, as long as the application interacts with Outlook using the Outlook object model and not MAPI. (For MAPI applications, see the section “MAPI Applications for Outlook” below.) COM manages the marshaling from the 32-bit application to 64-bit Outlook.
However, if you expect any existing unmanaged add-in will be run on computers with 64-bit Outlook 2010, you must recompile the add-in for 64-bit Outlook 2010. To clarify, you will have one version of the add-in to run on 32-bit Outlook, and another version of the add-in to run on 64-bit Outlook. Because there is no 64-bit Visual Basic 6.0 runtime, existing unmanaged add-ins written in Visual Basic 6.0 targeting to run on 64-bit Outlook 2010 should be rewritten, for example, as a managed add-in in Visual Basic.
*Note that even though you make calls the same way if you are targeting an add-in to run on 32-bit Outlook 2010 vs 64-bit Outlook 2010, there are changes in the Outlook 2010 object model such that, if you adapt an existing add-in to use the object model of Outlook 2010, you must be aware of the following:
· Object model calls in previous versions of Outlook were based on the assumption that there was only one Exchange account per profile. This assumption is not correct in Outlook 2010, since there can be multiple Exchange accounts per profile.
· Existing add-ins that modify a command bar or use Application events for shortcut menus may not work as expected in Outlook 2010. Update these add-ins to use the Office Fluent user interface extensibility. For more information, see Extending the User Interface in Outlook 2010.
I'm guessing ClearContext is an unmanaged add-in or you would have just recompiled with the Any CPU option and been done. As a result it looks like you have to rewrite your unmanaged add-in as a managed add-in to get it to work. I'm guessing Xobni was a managed add-in and was easier to just recompile without any code rewrite. If ClearContext is having to do code rewrite that explains why it's taking so long to get a x64 version ready.
by 
