none
Looking for a How To deploy an Outlook add-in on a client machine RRS feed

  • Question

  • I'm looking for add-in deployment help. To get the help I need I am giving background into where I'm at. 

    I tried adding the registry keys in my Visual Studio 2013 native COM Outlook add-in project (.rgs file) and copying the add-in library to the add-in directory on the client machine using Inno Setup to install the add-in. Outlook is not loading the add-in on launch.

    Trying to install the library manually on the same client machine in Outlook using the COM add-in dialog to load it invokes an error. It reads '[library absolute path] is not a valid Office add-in'.

    In researching how I should be deploy, I found two MS links. Troubleshooting Run Time Errors in Office Solutions which points me to use MSI technology, but doesn't say why. The second link Deploying Office Solutions says to use an MSI installer or ClickOnce. I'd like to use the MSI installer. Following the guidance leads me to create a Visual Studio setup project. There I see a project template under Setup and Deployment labeled Enable InstallSheild Limited Edition and its a 3rd party deal with Flextera Software. I'd use ClickOnce if I could learn how and it is the only free option.

    How can I deploy a native COM Outlook add-in to a client machine (win7, win8, win10, Outlook 2007+)?

    Thursday, November 26, 2015 4:46 PM

Answers

  • Joel,

    I suggest that you change the Visual Studio linker options to let the linker register your addin for you. Set Linker | General | Register Output to "Yes" and set Linker | General | Per-user Redirection to "Yes". If you have properly constructed the .rgs files for your addin the linker will properly register it for you.


    If you want to register the addin manually use regsvr32 to register the addin DLL.
    • Edited by RLWA32 Friday, November 27, 2015 5:02 PM
    • Marked as answer by Joel_Z Friday, November 27, 2015 6:05 PM
    Friday, November 27, 2015 4:58 PM

All replies

  • Hi Joel,

    There is a free add-in to Visual Studio from Microsoft that gives you the ability to create an MSI installer for your project.  Within Visual Studio go to Tools | Extensions and Updates.  You should find the Visual Studio 2013 MSI Installer in the Visual Studio Gallery under Tools | Setup and Deployment.

    Or, go to https://visualstudiogallery.msdn.microsoft.com/9abe329c-9bba-44a1-be59-0fbf6151054d

    BTW, did you look at that interface map?


    • Edited by RLWA32 Thursday, November 26, 2015 5:49 PM
    Thursday, November 26, 2015 5:46 PM
  • Hello Joel,

    Outlook is not loading the add-in on launch.

    There are plenty of possible causes why your add-in is not loaded. First of all, make sure that you included all the required prerequisites to the installer.

    Do you see the add-in listed in the COM add-ins list in Outlook? If not, you need to make sure all the required windows registry keys were created. See Registry Entries for VSTO Add-ins for more information. 

    Microsoft Office applications can disable VSTO Add-ins that behave unexpectedly. If an application does not load your VSTO Add-in, the application might have hard disabled or soft disabled your VSTO Add-in.

    Hard disabling can occur when an VSTO Add-in causes the application to close unexpectedly. It might also occur on your development computer if you stop the debugger while the Startup event handler in your VSTO Add-in is executing.

    Soft disabling can occur when a VSTO Add-in produces an error that does not cause the application to unexpectedly close. For example, an application might soft disable a VSTO Add-in if it throws an unhandled exception while the Startup event handler is executing.

    When you re-enable a soft-disabled VSTO Add-in, the application immediately attempts to load the VSTO Add-in. If the problem that initially caused the application to soft disable the VSTO Add-in has not been fixed, the application will soft disable the VSTO Add-in again. Read more about that in the How to: Re-enable a VSTO Add-in That Has Been Disabled article in MSDN.

    You may find the Troubleshooting COM Add-In load failures article helpful. 

    As for the MSI installer, you are not limited with InstallShield. You can install Microsoft Visual Studio 2013 Installer Projects and create MSI projects in VS2013. Also you may consider creating a WiX-based installer, see http://wixtoolset.org.

    The Deploying an Office Solution by Using Windows Installer article describes all the required steps for creating MSI installer. 

    Note, ClickOnce can be used for per-user add-ins only. You need to create an MSI installer if you need to deploy the add-in for all users. 

    Thursday, November 26, 2015 6:35 PM
  • Hi Joel,

    There is a free add-in to Visual Studio from Microsoft that gives you the ability to create an MSI installer for your project.  Within Visual Studio go to Tools | Extensions and Updates.  You should find the Visual Studio 2013 MSI Installer in the Visual Studio Gallery under Tools | Setup and Deployment.

    Or, go to https://visualstudiogallery.msdn.microsoft.com/9abe329c-9bba-44a1-be59-0fbf6151054d

    BTW, did you look at that interface map?


    I"m going to give the codeplex MSI installer project template a try. Thanks for that.

    I did see the ATL Interface map you posted. I didn't see anything suspect in mine when looking at it. I found a codeproject.com Outlook 2003 (ish) native example of the NewMail event, ran it and it worked. Using his example as a template, I added the ApplicationEvents_11 to add a hook for NewMailEx event and the NewMail event that once worked, hook stopped working and NewMailEx event didn't fire. I will probably just use the NewMail event.

    Thursday, November 26, 2015 6:50 PM
  • Hello Joel,

    Outlook is not loading the add-in on launch.

    There are plenty of possible causes why your add-in is not loaded. First of all, make sure that you included all the required prerequisites to the installer.

    Do you see the add-in listed in the COM add-ins list in Outlook? If not, you need to make sure all the required windows registry keys were created. See Registry Entries for VSTO Add-ins for more information. 

    Microsoft Office applications can disable VSTO Add-ins that behave unexpectedly. If an application does not load your VSTO Add-in, the application might have hard disabled or soft disabled your VSTO Add-in.

    Hard disabling can occur when an VSTO Add-in causes the application to close unexpectedly. It might also occur on your development computer if you stop the debugger while the Startup event handler in your VSTO Add-in is executing.

    Soft disabling can occur when a VSTO Add-in produces an error that does not cause the application to unexpectedly close. For example, an application might soft disable a VSTO Add-in if it throws an unhandled exception while the Startup event handler is executing.

    When you re-enable a soft-disabled VSTO Add-in, the application immediately attempts to load the VSTO Add-in. If the problem that initially caused the application to soft disable the VSTO Add-in has not been fixed, the application will soft disable the VSTO Add-in again. Read more about that in the How to: Re-enable a VSTO Add-in That Has Been Disabled article in MSDN.

    You may find the Troubleshooting COM Add-In load failures article helpful. 

    As for the MSI installer, you are not limited with InstallShield. You can install Microsoft Visual Studio 2013 Installer Projects and create MSI projects in VS2013. Also you may consider creating a WiX-based installer, see http://wixtoolset.org.

    The Deploying an Office Solution by Using Windows Installer article describes all the required steps for creating MSI installer. 

    Note, ClickOnce can be used for per-user add-ins only. You need to create an MSI installer if you need to deploy the add-in for all users. 


    I appreciate the information, Eugene. I tried the troubleshooting tips for COM (not VSTO) yesterday and none worked. I may have mucked up my registry or Outlook installation during the Inno Setup registry setting testing, so I'm doing a clean install of my test VM to start over with.
    Thursday, November 26, 2015 6:55 PM
  • Pay special attention to the windows registry keys and prerequsites required for the add-in.
    Thursday, November 26, 2015 7:06 PM
  • Pay special attention to the windows registry keys and prerequsites required for the add-in.

    Will do. I've downloaded the VS Setup and Deployment template RLWA32 suggested and started a project following the Office Solution deployment walkthrough moving away from Inno Setup. 

    In the walkthrough, there is a Windows Registry data name Manifest to create with a datavalue of file:///[INSTALLDIR]ExcelAddIn.vsto|vstolocal. I think this is in part what I had been missing.

    It sounds like I need to deploy the C:\VS2013\VC\redist\1033\vcredist_x64.exe as part of the installation to the client and that I need to create an Xml manifest for the install too.

    I had read on an MS Office blog yesterday that VSTO implies .NET type projects. I'm going against that point and just doing the VSTO walkthrough even though I don't have a .NET project.


    • Edited by Joel_Z Thursday, November 26, 2015 8:18 PM
    Thursday, November 26, 2015 8:17 PM
  • I mentioned it too.

    There is no need to deploy VSTO or .Net if you develop unmanaged add-ins (raw C++). In case if you use C++/CLI you will need to include .net as a prerequisite to the installer.  

    Thursday, November 26, 2015 8:49 PM
  • I mentioned it too.

    There is no need to deploy VSTO or .Net if you develop unmanaged add-ins (raw C++). In case if you use C++/CLI you will need to include .net as a prerequisite to the installer.  

    How can I deploy a native (raw C++) COM Outlook add-in?

    • Edited by Joel_Z Thursday, November 26, 2015 9:51 PM
    Thursday, November 26, 2015 9:50 PM
  • Joel,

    Take a look at the following pages in MSDN:

    Walkthrough: Deploying Your Program (C++)

    Deploying Native Desktop Applications (Visual C++)

    Walkthrough: Deploying a Visual C++ Application to an Application-local Folder

    Don't forget to add the required windows registry keys for the add-in.

    Friday, November 27, 2015 3:44 AM
  • Joel,

    Take a look at the following pages in MSDN:

    Walkthrough: Deploying Your Program (C++)

    Deploying Native Desktop Applications (Visual C++)

    Walkthrough: Deploying a Visual C++ Application to an Application-local Folder

    Don't forget to add the required windows registry keys for the add-in.


    To clarify my problem I need help with, I'm specifically looking for Outlook 2007+ add-in deployment assistance. To deploy on a Win7 x64 and Office 2013 x64 machine, I added the registry keys from my Visual Studio 2013 native COM Outlook add-in project (.rgs file) and then copied the add-in library to the add-in directory on the client machine. Outlook is not loading the add-in on launch. Trying to load the library manually using the COM add-in dialog  invokes an error ' like c:\Users\505hpc6z06\appdata\Roaming\Microsoft\AddIns\MyAddin.dll is not a valid Office add-in'.

    These are the registry keys I added (not in wow64 registry node). In place of %MODULE% , I put the absolute path of the MyAddin.dll. something like c:\Users\505hpc6z06\appdata\Roaming\Microsoft\AddIns\MyAddin.dll

        HKCR
        {
            NoRemove CLSID
            {
                ForceRemove {EB824C19-380D-417E-A9E2-28E77B2F3026} = s 'CompReg Class'
                {
                    InprocServer32 = s '%MODULE%'
                    {
                        val ThreadingModel = s 'Apartment'
                    }
                    TypeLib = s '{B0A51D8E-5E5A-447B-B935-765F3BC5C79F}'
                    Version = s '1.0'
                }
            }
        }
        HKCU
        {
            NoRemove Software
            {
                NoRemove Microsoft
                {
                    NoRemove Office
                    {
                        NoRemove Outlook
                        {
                            NoRemove Addins
                            {
                                FromCloud.Connect
                                {
                                    val Description = s 'My Outlook Addin'
                                    val LoadBehavior = d 3
                                }
                            }
                        }
                    }
                }
            }
        }


    Friday, November 27, 2015 4:42 PM
  • Joel,

    I suggest that you change the Visual Studio linker options to let the linker register your addin for you. Set Linker | General | Register Output to "Yes" and set Linker | General | Per-user Redirection to "Yes". If you have properly constructed the .rgs files for your addin the linker will properly register it for you.


    If you want to register the addin manually use regsvr32 to register the addin DLL.
    • Edited by RLWA32 Friday, November 27, 2015 5:02 PM
    • Marked as answer by Joel_Z Friday, November 27, 2015 6:05 PM
    Friday, November 27, 2015 4:58 PM
  • Joel,

    I suggest that you change the Visual Studio linker options to let the linker register your addin for you. Set Linker | General | Register Output to "Yes" and set Linker | General | Per-user Redirection to "Yes". If you have properly constructed the .rgs files for your addin the linker will properly register it for you.


    If you want to register the addin manually use regsvr32 to register the addin DLL.

    I had a working add-in, then I start having problems with the library failing to load on my dev box. So I tried a test machine and Outlook fails to load the add-in as well.

    I just now looked at my Windows Update history and see I installed a bunch of Office updates (qty. 30+) on the 25th on my Win8.1 dev machine. The day this add-in load problem started happening. Coincidence?


    • Edited by Joel_Z Friday, November 27, 2015 6:10 PM
    Friday, November 27, 2015 6:05 PM
  • Are you using the right version of regsvr32 ( 64 bit vs 32 bit)?

    I uploaded a revised sample project that resolves the failure to receive the NewMailEx event.  I suggest you download that and build it to see if it gets registered.


    You should verify that the resource ID in the DECLARE_REGISTRY_RESOURCEID macro refers to the resource ID for the .rgs file that is used in the registration process.
    • Edited by RLWA32 Friday, November 27, 2015 7:36 PM added suggestion
    Friday, November 27, 2015 6:19 PM
  • Are you using the right version of regsvr32 ( 64 bit vs 32 bit)?

    I uploaded a revised sample project that resolves the failure to receive the NewMailEx event.  I suggest you download that and build it to see if it gets registered.


    You should verify that the resource ID in the DECLARE_REGISTRY_RESOURCEID macro refers to the resource ID for the .rgs file that is used in the registration process.

    The 64 bit regsvr32 was used. It was called outside the system directory so I think it is the non-wow64 version.

    I used sysinternals procmon.exe to monitor registry and file handles/access while loading the add-in library from Outlook. In the procmon log data, the TypeLib GUID for the add-in was not in the logging that I had added to the registry to load the library.

    In regards to the resource ID reference in  DECLARE_REGISTRY_RESOURCEID(IDR_CONNECT), IDR_CONNECT is defined as 106. I'm not sure how to validate the .rgs file is using that ID.

    In looking at the .rgs file and comparing the typelib GUID to the IDL, I think that looks OK. The CompReg Class GUID and the TypeLib GUID in the .rgs matches the library IDL. 

    I think I might re-do my dev VM. This is a confusing problem and shouldn't have happened.

    [
    	object,
    	uuid(a817e7a2-43fa-11d0-9e44-00aa00b6770a),
    	dual,	
    	pointer_default(unique)
    ]
    interface IComponentRegistrar : IDispatch
    {
    	[id(1)]	HRESULT Attach([in] BSTR bstrPath);
    	[id(2)]	HRESULT RegisterAll();
    	[id(3)]	HRESULT UnregisterAll();
    	[id(4)]	HRESULT GetComponents([out] SAFEARRAY(BSTR)* pbstrCLSIDs, [out] SAFEARRAY(BSTR)* pbstrDescriptions);
    	[id(5)]	HRESULT RegisterComponent([in] BSTR bstrCLSID);
    	[id(6)] HRESULT UnregisterComponent([in] BSTR bstrCLSID);
    };
    
    [
    	object,
    	uuid(646705E4-11B1-4AFB-B151-D1F79B7E99C5),
    	oleautomation,
    	nonextensible,
    	pointer_default(unique)
    ]
    interface IFromCloud : IUnknown{
    };
    [
    	uuid(B0A51D8E-5E5A-447B-B935-765F3BC5C79F),
    	version(1.0),
    	custom(a817e7a1-43fa-11d0-9e44-00aa00b6770a,"{EB824C19-380D-417E-A9E2-28E77B2F3026}")
    ]
    library FromCloudLib
    {
    	importlib("stdole2.tlb");
    	[
    		uuid(EB824C19-380D-417E-A9E2-28E77B2F3026)		
    	]
    	coclass CompReg
    	{
    		[default] interface IComponentRegistrar;
    	};
    	[
    		uuid(9541D845-48A1-4196-AFAC-43B0B21C1B16)		
    	]
    	coclass FromCloud
    	{
    		[default] interface IRibbonCallback;
    	};
        [
            object,
            uuid(CE895442-9981-4315-AA85-4B9A5C7739D8),
            dual,
            nonextensible,
            helpstring("IRibbonCallback Interface"),
            pointer_default(unique)
        ]
        interface IRibbonCallback : IDispatch{
            [id(42),helpstring("Button Callback")]
            HRESULT ButtonClicked([in]IDispatch* ribbonControl);
        };
    };


    • Edited by Joel_Z Friday, November 27, 2015 10:30 PM
    Friday, November 27, 2015 10:29 PM
  • Make sure to look at that project that I uploaded to onedrive for you.  Examine the code changes that I made and the IDL.

    I suggest you scrap the IDL above and start over with the sample projecdt (as modified).

    IFromCloud should be derived from IDispatch, not IUnknown

    The default interface in the FromCloud CoClass should be IFromCloud, not IRibbonCallback.

    You don't need IRibbonCallback or the IDispatch::INvoke override at all.  That code is a mess.

    Friday, November 27, 2015 10:46 PM
  • Make sure to look at that project that I uploaded to onedrive for you.  Examine the code changes that I made and the IDL.

    I suggest you scrap the IDL above and start over with the sample projecdt (as modified).

    IFromCloud should be derived from IDispatch, not IUnknown

    The default interface in the FromCloud CoClass should be IFromCloud, not IRibbonCallback.

    You don't need IRibbonCallback or the IDispatch::INvoke override at all.  That code is a mess.

    I appreciate the suggestions, sample and your time. I'm going to redo the event handling in my project once its running again.

    I had tried creating a new project today from scratch on both my machines. Win8.1 x64 with Office 2013 (and all updates) and Win7 x64, VS2015 and Office 2013 (no updates). In VS when implementing the _IDTExtensibility2 in the ATL Simple Object, an error occurs when clicking finish. It reads "Error in OnFinish". I thought no problem, I did this before. I found the site with the tip that worked  and the work-around didn't resolve the problem. At this point I'm going to redo my machines. Win7, VS2010.

    I built the project in VS2013 Update 4 in x64 flavor and tried installing it on a win7 x64 test machine having Outlook 2013. The regsvr32 failed, but with a different error. I think it should have worked.

     

    Friday, November 27, 2015 11:10 PM
  • I built the project in VS2013 Update 4 in x64 flavor and tried installing it on a win7 x64 test machine having Outlook 2013. The regsvr32 failed, but with a different error. I think it should have worked.

     

    If you mean the sample project that I uploaded the first thing to do is to make sure that all of the settings for an x64 build mirrored the ones for x86. If you did that then the linker options were set up to register the DLL (per-user registration) and Outlook should be able to load it from the location where the linker wrote it's output (the DLL).  It shouldn't have been necessary to run regsvr32

    • Edited by RLWA32 Saturday, November 28, 2015 12:44 AM
    Saturday, November 28, 2015 12:43 AM
  • I built the project in VS2013 Update 4 in x64 flavor and tried installing it on a win7 x64 test machine having Outlook 2013. The regsvr32 failed, but with a different error. I think it should have worked.

     

    If you mean the sample project that I uploaded the first thing to do is to make sure that all of the settings for an x64 build mirrored the ones for x86. If you did that then the linker options were set up to register the DLL (per-user registration) and Outlook should be able to load it from the location where the linker wrote it's output (the DLL).  It shouldn't have been necessary to run regsvr32

    I used the Build Configuration utility to change to x64. When I launched the Project (F5), Outlook launched but the add-in didn't load. The library wasn't in the COM add-in dialog in Outlook. Same behavior as the add-in I'm working on.

    I copied the TestAddIn2.dll it over to a test machine to register it since the test system doesn't have VS installed. I gave up on my dev environment and I'm re-building it. Hopefully some of these problems will go away.

    Saturday, November 28, 2015 1:28 AM
  • Unfortunately I don't have 64 bit Outlook so I can't duplicate your environment. If you create a downloadable project I can test it in an Outlook 2013 32 bit environment.

    There are probably other settings in the project that you should check for x64.  For example, check the settings under Linker | Advanced | Target Machine and make sure that is set for a 64 bit machine.

    Saturday, November 28, 2015 2:19 AM
  • I re-did my dev environment and the same issues exist. My project library wont register and creating new project fails. When using the Implement Interface Wizard, clicking finish after adding the _IDTExtensibility2 interface gets an error dialog "Error OnFinish.". I'm going to give this project a break. 
    Saturday, November 28, 2015 3:31 AM
  • I understand the frustration.  See https://social.msdn.microsoft.com/Forums/office/en-US/00946d1f-e323-4c40-881f-6e48512f6385/bug-atl-implement-interface-wizard-always-prompt-error?forum=outlookdev

     If you have another version of Visual Studio available you might be able to use it to create the project and then continue on using that new project with VS2013.

    Saturday, November 28, 2015 4:38 AM
  • Looks like the issue was related to adding the required windows regisrty keys using C++. If so, I'd recommend asking C++ specific questions on the Visual C++ forum where you may reach a far more audience.

    The current forum is for Outlook specific questions.

    Saturday, November 28, 2015 3:08 PM
  • Joel,

    I have uploaded a solution that contains an x64 addin for Outlook and also an x64 Visual Studio Installer project.

    You will have to change the #import statements in stdafx.h to point to the location of the type libraries on your own system.

    The addin receives the NewMailEx event and in debug mode it logs the entry id to the debugger's output window.  It also puts a button on the Explorer Ribbon that, when pressed, pops up a message box.

    The project compiler settings are set to use the static versions of the CRT to avoid creating any DLL dependencies that would require the VC++ runtime redistributable.  Consequently, the installer project settings do not create a bootstrapper setup program since there are no prerequisites for this simple addin.  Only an msi file is generated in debug and release modes.

    The addin was initially created using VS2010 and I also built it successfully with VS2013 which is what the uploaded zip file contains.  The installer msi files and addin DLLs created by both versions of Visual Studio were successfully installed, tested, and uninstalled on Outlook 2010 x64.

    You can download the solution from OutCloud.zip
    Sunday, November 29, 2015 3:51 PM
  • Joel,

    I have uploaded a solution that contains an x64 addin for Outlook and also an x64 Visual Studio Installer project.

    You will have to change the #import statements in stdafx.h to point to the location of the type libraries on your own system.

    The addin receives the NewMailEx event and in debug mode it logs the entry id to the debugger's output window.  It also puts a button on the Explorer Ribbon that, when pressed, pops up a message box.

    The project compiler settings are set to use the static versions of the CRT to avoid creating any DLL dependencies that would require the VC++ runtime redistributable.  Consequently, the installer project settings do not create a bootstrapper setup program since there are no prerequisites for this simple addin.  Only an msi file is generated in debug and release modes.

    The addin was initially created using VS2010 and I also built it successfully with VS2013 which is what the uploaded zip file contains.  The installer msi files and addin DLLs created by both versions of Visual Studio were successfully installed, tested, and uninstalled on Outlook 2010 x64.

    You can download the solution from OutCloud.zip

    RLWA32, I'm excited to be getting help from you on this. I had picked up the last project you posted yesterday. Using it as well as your advice, my dev box is now Outlook add-in compatible again. The NewMailEx event was firing from your TestAddin2 project. I leveraged your source code applying the event handling to a new VS project combining source from my old project and the NewMailEx event fired. But I broke the ribbon button that would normally invoke my Dialog in that it doesn't fire. When the ribbon button is clicked, debug spews out that reads "ERROR : Unable to load Typelibrary. (HRESULT = 0x8002801d), Verify TypelibID and major version specified with IDispatchImpl, CStockPropImpl, IProvideClassInfoImpl or IProvideCLassInfo2Impl".

    I looked to the windows registry and found one of the .rgs project files wasn't registered. So I added the keys manually paying attention to the library GUID's and compared the registry key structure to the TestAddin2 project and both .rgs files to validate the keys were added correctly. The button event still didn't fire and the same error message spews out. 

    I'm going to pick up your OutCloud.Zip now and leverage it to resolve this ribbon button invocation problem and if that doesn't work, I can now create a new project and try again :)

    Even though these Outlook add-ins are working on my dev box, they still are refusing to deploy on a fresh Win7x64/Outlook 2013 test box. Outlook invokes the same error as this post was started from. When adding the library VIA COM add-in dialog, an error occurs that reads "c:\Path\xyz.dll is not a valid Office add-in." Regsvr32 also fails with the error I posted earlier in this thread. Regsvr32 succeeded with both the libraries on the dev box (win7x64, Outlook 2013, VS2012, VS2015).

    I can see that you have overcome similar Outlook developer problems using Native programming. I'm grateful to be able to come here and receive help from you. I think Microsoft is proud to have you in their forum.  

    • Edited by Joel_Z Sunday, November 29, 2015 5:37 PM
    Sunday, November 29, 2015 5:36 PM
  • Joel,

    The OutCloud add-in should appear in Outlook's COM add-in dialog box after you build the installer and run it.  You can install the add-in using the installer from within Visual Studio by building the installer and then right clicking on the installer project and selecting "Install".  Of course you can also install it by navigating to the folder where the msi file resides and double clicking it or using the right click context menu on the msi file.

    The linker options in the visual studio project are NOT set to register the DLL.  That is the job of the installer which will take care of it using the DLL's registration functions.  This will take care of the necessary COM stuff (CLSID, Interface, Typelib, etc)

    The .rgs file for the addin does NOT contain the registry entry to register the add-in with the Outlook's COM-Addin dialog.  That is taken care of by the installer and you can see the necessary entries in the registry entry pane of the installer project in Visual Studio.  It should not be necessary for you to do anything other than run the installer.


    Sunday, November 29, 2015 6:39 PM
  • Joel,

    The OutCloud add-in should appear in Outlook's COM add-in dialog box after you build the installer and run it.  You can install the add-in using the installer from within Visual Studio by building the installer and then right clicking on the installer project and selecting "Install".  Of course you can also install it by navigating to the folder where the msi file resides and double clicking it or using the right click context menu on the msi file.

    The linker options in the visual studio project are NOT set to register the DLL.  That is the job of the installer which will take care of it using the DLL's registration functions.  This will take care of the necessary COM stuff (CLSID, Interface, Typelib, etc)

    The .rgs file for the addin does NOT contain the registry entry to register the add-in with the Outlook's COM-Addin dialog.  That is taken care of by the installer and you can see the necessary entries in the registry entry pane of the installer project in Visual Studio.  It should not be necessary for you to do anything other than run the installer.


    Wow, that worked seamlessly! What a beauty. It would have taken me forever to figure that out!

    I think you bring significant value to this forum as an Outlook developer by solving hard problems. I'd up-vote you 20 times if I could!

    Sunday, November 29, 2015 8:47 PM
  • I'm very glad that we've gotten past the earlier problems. I know how hard it can be to resolve the kinds of problems that you have bumped up against.  You kept going instead of giving up and the time that I devoted to providing those samples to you was well worth it.  :)

    Take the time to study the ATL COM and installer documentation.  And now that you have a working sample you can see how it fits together and you can also see the impact of making changes to that starting point.  That's an investment that will pay dividends.

    Sunday, November 29, 2015 9:12 PM
  • I'm very glad that we've gotten past the earlier problems. I know how hard it can be to resolve the kinds of problems that you have bumped up against.  You kept going instead of giving up and the time that I devoted to providing those samples to you was well worth it.  :)

    Take the time to study the ATL COM and installer documentation.  And now that you have a working sample you can see how it fits together and you can also see the impact of making changes to that starting point.  That's an investment that will pay dividends.


    I've been trying to get an x86 install working since yesterday and need to reach out for help. I built an x86 version of my add-in to deploy to a x64 windows 7 OS with Outlook x86 2013 installed. The add-in doesn't load. It does load on x64 Outlook (with x64 image/binary). I'm wondering how an x86 install would differ? The install project I'm using [removed]. I'm looking for help trying to install the add-in on x86 and can't find the right documentation that would shed light on how to deploy this.
    • Edited by Joel_Z Saturday, December 5, 2015 12:41 AM
    Friday, December 4, 2015 8:26 PM
  • Hi Joel,

    Did you remember to change the platform for the installer project from x64 to x86?

    Friday, December 4, 2015 8:41 PM
  • yes, it was using the Active configuration which is x86. the linker command line is correct, using the x86 architecture.


    • Edited by Joel_Z Friday, December 4, 2015 8:50 PM
    Friday, December 4, 2015 8:47 PM
  • Joel,

    Slow down, my friend.  I asked about the installer project, not the project that creates the addin.  The installer project has its own platform setting that you should find among the installer project properties.  When I created OutCloud it was set for x64.  That was fine for an x64 version of Outlook.  For an x86 version of Outlook the installer project platform should be x86 also.

    Friday, December 4, 2015 8:52 PM
  • Joel,

    Slow down, my friend.  I asked about the installer project, not the project that creates the addin.  The installer project has its own platform setting that you should find among the installer project properties.  When I created OutCloud it was set for x64.  That was fine for an x64 version of Outlook.  For an x86 version of Outlook the installer project platform should be x86 also.

    Yeah, I'm overwhelmed. Its D-day.

    The project platform configuration is Release Win32, not Release x86. I thought those were one in the same, but I will create a new configuration named x86. The HKCR appid isn't getting created.

    Friday, December 4, 2015 9:01 PM
  • Joel,

    Don't create another configuration yet.

    In the solution explorer select the installer project.  Right click and select "properties".  A property window/pane should open.  There is a platform setting.  What does it say?

    Friday, December 4, 2015 9:03 PM
  • It reads N/A. When using the drop down to change the value, no other values exist to switch to. N/A is the only option.
    Friday, December 4, 2015 9:12 PM
  • Friday, December 4, 2015 9:15 PM
  • Hmm, that doesn't make sense to me.  If you're in a hurry and you have Visual Studio installed on a 32 bit version of Windows it would certainly be faster to use that to build a 32 bit addin with a 32  bit installer.
    Friday, December 4, 2015 9:16 PM
  • I may have sent you to the wrong property settings window.  I did it from memory and didn't have visual studio open in front of me.  There is a different window with installer project properties that I'll post a screen shot for as soon as I can get VS up and running on a dev system.  Hang tight for a few more moments...
    • Edited by RLWA32 Friday, December 4, 2015 9:28 PM
    Friday, December 4, 2015 9:27 PM
  • Thanks, RLWA32. I think the problem is what I hear you questioning and that is the platform architecture of the installation project for the Outlook add-in.
    Friday, December 4, 2015 9:29 PM
  • Joel,

    Select the installer project in solution explorer.  From the main menu select View | Other Windows | Properties Window.  You should see something that looks like this. --

    Friday, December 4, 2015 9:34 PM
  • wow, it was x64. I'm trying it out now.
    Friday, December 4, 2015 9:38 PM
  • Its the right arch now, but same problem. Outlook may not be loading it because the CLSID for the add-in library doesn't exist in the registry. I think once I get that going (Inno Setup and calling regsvr32 with the Outlook add-in keys created), that may fix this.

    I was looking for the properties window for the setup project and, silly me had the properties window in the same pane. All I had to do was switch tabs to find all those settings :)

     
    Friday, December 4, 2015 9:51 PM
  • I'm not sure how you've created your addin project, installer project.  If you can create a small sample (something like OutCloud) that shows how you're handling the registry, etc. and upload it to onedrive I'd be happy to take a look at it.  Why do you need Inno Setup?
    • Edited by RLWA32 Friday, December 4, 2015 9:56 PM
    Friday, December 4, 2015 9:55 PM
  • Inno setup allows creating the Outlook add-in keys manually (with a creation syntax string), it was an idea to move forward. But hearing you are open to reviewing a project, I'd like to go that route. I appreciate this.

    Friday, December 4, 2015 10:01 PM
  • BTW, please upload a solution that can be opened in visual studio so that I can use it to build the add-in dll and the installer.  That will give me the most insight into what you're doing.
    Friday, December 4, 2015 10:04 PM
  • I just recovered and deployed the OutCloud project you had provided successfully to the same test machine. I think my problem can be found by diffing/comparing the two projects. I had not thought of running OutCloud until now because the x64 version of my current project worked fine after clean installs of the test machine. It was a bad assumption on my part to think OutCloud had the same behavior. I think I have what I need now to find the problem. I appreciate your input and guidence. 

    Friday, December 4, 2015 10:27 PM
  • So you were able to use OutCloud to build and deploy an x86 add-in?
    Friday, December 4, 2015 10:35 PM
  • Yes. From that discovery, I copied and pasted the installer project file overwriting what I had. Then did a clean install of the test machine to test the add-in. The install worked. I just shipped! Wow, that was intense. I think my mistake was editing the project file in text and not using the property window (because I didn't see it :)). Thanks a bunch, RLWA32!
    Friday, December 4, 2015 11:13 PM
  • I'm very happy for you.  It's Miller Time!
    Friday, December 4, 2015 11:43 PM