none
Documentation for development of add-in targeting Outlook 2010 x64? RRS feed

  • Question

  • I need to port an add-in for Outlook 2010 (that also works with 2007) to Outlook 2010 x64.  I have not been able to find really good documentation for this, something like the Carter and Lippert books on VSTO targeting Office 2007 and 2005.  Any suggestions?
    mdpowers
    Wednesday, January 18, 2012 5:47 PM

All replies

  • For a VSTO addin you don't need to do anything at all if you're using VSTO 4. The addin should install and run on Outlook 2010 x64 with no changes.
     
    If you use pointers or anything like that you might want to check the size of IntPtr to see if it's 4 or 8 bytes, but something like that is about all you need to do.

    --
    Ken Slovak
    MVP - Outlook
    http://www.slovaktech.com
    Author: Professional Programming Outlook 2007
     
     
    "mdpowers-slo" <=?utf-8?B?bWRwb3dlcnMtc2xv?=> wrote in message news:f0ed0239-0f11-4012-be2e-e34c66c3cd95...
    I need to port an add-in for Outlook 2010 (that also works with 2007) to Outlook 2010 x64.  I have not been able to find really good documentation for this, something like the Carter and Lippert books on VSTO targeting Office 2007 and 2005.  Any suggestions?
    mdpowers

    Ken Slovak MVP - Outlook
    Wednesday, January 18, 2012 5:52 PM
  • VSTO4 ... that's the VSTO in VS2010, right?  I must be doing something wrong then, because the add-in will not load on Outlook 2010 x64. 

    FWIW, the add-in references some other DLLs ... do all DLLs need to be compiled as x64, or can I compile them as 'Any CPU'?  Also, I'm currently installing the add-in to a subfolder of our main application, which gets installed to the x86 pranch of Porgram Files; is this a no-no?


    mdpowers
    Wednesday, January 18, 2012 6:07 PM
  • Managed code addins would be compiled as "Any", that will work on x86 or x64. Unmanaged code such as C++ code would need to be compiled for the specific processor used.
     
    You do need to make sure all requirements are there, just as you'd do with x86. As far as where the code is installed I've only installed it under x86 for x86 machines, where I install on x64 the installation goes to Program Files, but I have no idea if that would be a problem. Try it and see.
     
    I currently have 5 addins set up to run under VSTO 4 (VS 2010) that run with no changes on either x86 or x64.
     
    Where I have shared addins running in both CPU sizes I do have to use a different shim dll and compile that for x64 (C++ code), but for my VSTO addins I've made no changes at all to the actual code or the installers.

    --
    Ken Slovak
    MVP - Outlook
    http://www.slovaktech.com
    Author: Professional Programming Outlook 2007
     
     
    "mdpowers-slo" <=?utf-8?B?bWRwb3dlcnMtc2xv?=> wrote in message news:819bc0e2-9a00-4e03-9cb8-434851932fc6...

    VSTO4 ... that's the VSTO in VS2010, right?  I must be doing something wrong then, because the add-in will not load on Outlook 2010 x64. 

    FWIW, the add-in references some other DLLs ... do all DLLs need to be compiled as x64, or can I compile them as 'Any CPU'?  Also, I'm currently installing the add-in to a subfolder of our main application, which gets installed to the x86 pranch of Porgram Files; is this a no-no?


    mdpowers

    Ken Slovak MVP - Outlook
    Wednesday, January 18, 2012 6:17 PM
  • This is a managed add-in, and do not explicitly use pointers. 

    Maybe the thing to try first is to install the x64 edition on my development machine, get it working under Debug first, then work on the deployment part.

    Do all DLLs referenced by the add-in have to be 'Any CPU'?  Our own DLLs I can recompile, but not third party components; is there something I can check in the properties of a DLL that would let me know for sure what it was compiled for?

    Our main application we have been compiling as 'x86' because there were some problems with 'Any CPU' under VS2005; is this still a concern under VS2010?


    mdpowers
    Wednesday, January 18, 2012 6:28 PM
  • DLL's that are compiled from managed code should be compiled as Any. If you do compile them as x86 they would only work in the x86 addin. You would need a set compiled as x64 in that case and you'd need to load the correct one for the runtime bitness. So Any is better.
     
    Unmanaged code dll's cannot be compiled as Any. They would be compiled for x86 or x64 and the one with hte appropriate bitness would be loaded at runtime. DLL's in C++ fall into this category even if using managed C++.
     
    A 3rd party DLL can be anything: managed, unmanaged, written using C++ or any other language. You'd need to find out from the vendor what bitness the DLL has. DLL's written using a language such as VB 6 can only be x86 and cannot be used from an x64 addin.The same would apply to DLL's written using Delphi, or any other language that doesn't have an x64 compiler.
     
    I've had no problems with compiling for Any in VS 2010.

    --
    Ken Slovak
    MVP - Outlook
    http://www.slovaktech.com
    Author: Professional Programming Outlook 2007
     
     
    "mdpowers-slo" <=?utf-8?B?bWRwb3dlcnMtc2xv?=> wrote in message news:2a3c8124-11ec-4901-a5b2-b121b8c5aa78...

    This is a managed add-in, and do not explicitly use pointers. 

    Maybe the thing to try first is to install the x64 edition on my development machine, get it working under Debug first, then work on the deployment part.

    Do all DLLs referenced by the add-in have to be 'Any CPU'?  Our own DLLs I can recompile, but not third party components; is there something I can check in the properties of a DLL that would let me know for sure what it was compiled for?

    Our main application we have been compiling as 'x86' because there were some problems with 'Any CPU' under VS2005; is this still a concern under VS2010?


    mdpowers

    Ken Slovak MVP - Outlook
    Wednesday, January 18, 2012 7:13 PM