Hello guys,

We've been getting a lot of requests about how one can install the files for an Office Add-In based on the Office bitness (based on whether the Office is x86 or x64).

Today we will be going through this scenario, step by step and hopefully, at the end of this How-To, things will be clearer for you.

Prerequisites:

1. Advanced Installer Professional edition or above

2. Another prerequisite here would be to have your own Add-In. In my sample, I have created a Word Add-in which I will provide at the end of this How-To. However, since we will be going through this step by step, you will be able to generate your Add-In installer for your own Add-In.

With that being said, let's get this started.

- First thing you have to do is to open Advanced Installer, go to "Add-Ins" tab from "Project Category" and double click on the "Office Add-In". This will spawn a wizard which will guide you through the rest of the process.

- The first step of the Wizard will be to specify the Product Name and the Product Manufacturer:

- The next step will be choosing the package type (e.g. MSI, EXE, etc.)

- The next step will be choosing the location where the project will be saved / (&later) built

- The next step will be choosing the Add-In type we want to deploy. For this, I have chosen the "Deploy a VSTO Office Add-In" (since the Add-in was created using Visual Studio Tools for Office (VSTO))

- The next step will be selecting the location of the Add-In resources. In my case, I will be importing my files from the Visual Studio Solution

- Next, we will need to select the project configuration which we want to import. In my case, I will be importing the "Debug" configuration, since that is where my files reside

As you can see in the above screenshot, you can also opt for building the configuration by selecting the "Build selected configuration before proceeding" option. However, this is not the case for me, since I've already built the configuration before starting the Wizard.


- In the next step, the files will be automatically detected and you can choose which files should be added to the project

- In the next steps, you will be able to provide some additional information, such as:


1. The version of Visual Studio Tools for Office used


2. The targeted Microsoft Office version


3. The targeted Microsoft Office Product

4. The Add-in description, friendly name, behavior, etc.

5. Add-In launch conditions and prerequisites. In my case, I will leave all these uncheked (just for the sake of making the project as simple as possible. Also, I have everything needed already installed).

6. The package language. In my case, I will be going for the English language. However, feel free to add more, if needed.

7. The possibility to add the License Agreement dialog to your project.

8. Least but not last, the final dialog from the Wizard will be the one that lets you build your project. Here, please click "Finish"

Now that we have completed the Wizard, it is time to configure the project as per our needs. As explained in the title, we will not be looking into installing the resources based on the Office bitness.

Basically, what should be noted here is the fact that only the registry entries are different. Upon completing the Office Add-In wizard, if we go to "Registry" page, we can notice the fact that, beside the default registry entries that are automatically added in every Advanced Installer project, few more entries are added that are specific to Office Add-Ins.
In the above screenshot, you can notice the following values: Description, FriendlyName, LoadBehavior and Manifest which are located under:

HKLM:\Software\Microsoft\Office\Word\AddIns\[Manufacturer].[ProductName]

The above key is present when going into the "Registry" page. However, in my screenshot, you will see two keys:[Manufacturer].[ProductName]_x86 and [Manufacturer].[ProductName]_x64. Basically, what I have done here is duplicating the registry entry and simply changing their names. In order to copy the key, please select it --> press CTRL+C --> select the "AddIns" key and press CTRL+V. After doing so, you can select each key and press F2 to rename it.

Every registry value from the "Registry" page is reflected into the "Organization" page as a component. Due to the fact that we have duplicated the key, we will now have 8 distinct components in "Organization" page, such as:

1. Description, respectively Description_1

2. FriendlyName, respectively FriendlyName_1

3. LoadBehavior, respectively LoadBehavior_1

4. Manifest, respectively Manifest_1

Here, in order to make an easier to follow UI, I have created, under the MainFeature feature, two subfeatures as it follows: AddIn_x86 and AddIn_x64. In order to create a sub feature, please click on MainFeature feature --> "New Feature"

Now, what I would like to do here is to move the earlier specified components to their appropriate features:

a) please move the following components: Description, FriendlyName, LoadBehavior and Manifest to the "AddIn_x86" feature. In order to move a component to another feature, simply select the component and then drag and drop it to the appropriate feature.

b) please move the following components: Description_1, FriendlyName_1, LoadBehavior_1 and Manifest_1 to the "Addin_X64" feature.

In the end, it should look like this:


Important: Please select each component from the "Addin_x64" feature and check the "64-bit Component" option for it


Basically, what we would like to do now is to condition each feature to install based on the Office bitness. The Office package is a really complex one, but after some research time, I've decided to take its bitness based on the following registry entry:

HKLM:\SOFTWARE\Microsoft\Office\16.0\Access\InstallRoot\Path

Here is how this work: we will have two searches, both looking for this path, one set to look in the 64-bit location and one in the 32-bit location.

In order to achieve this, please go to "Search" page and create two searches:

WORD_x64_EXISTS

and

WORD_x86_EXISTS

- now please right click on the WORD_x64_EXISTS --> "Add search location" --> "Registries". The search should look like this:

It's important to check the "Search the 64-bit portion of the registry" option for this. This way, the search will be looking in the following location:

HKLM:\SOFTWARE\Microsoft\Office\16.0\Access\InstallRoot\Path

- now please repeat the above step for the second search. Here it is important to not check the "Search the 64-bit portion of the registry". This way, the search will be looking in the following location:

HKLM:\SOFTWARE\WOW6432NODE\Microsoft\Office\16.0\Access\InstallRoot\Path

Now please go to back to "Organization" page, select the AddIn_x64 feature and, under "Installation Behavior" section set its behavior to "Not installed" by default and "Installed if":

WORD_x64_EXISTS

Now please repeat the above step for the "AddIn_x86" feature as well. This time, please set the condition to:

WORD_x86_EXISTS

Build & run the project. Now your Office AddIn should be installed based on the Office bitness.

Please find attached, as promised, the projects for your reference:

In the above .ZIP file, you can find both the Visual Studio solution and the Advanced Installer project.

Hope this helps.

Best regards,
Catalin

Thank you for this tutorial, Catalin. It was very helpful.

Is there a reason you didn't use the Office "Bitness" registry setting to check the bitness of the installation?

I found this other article on this that seems to work for me. Are there cases where it won't?

keith.

Hello and welcome to Advanced Installer forums, Keith.

You are always welcome.

I am really glad you found this tutorial helpful.

In what regards the registry key, could you please re-link me the article you were talking about (it seems that your hyperlink points to this tutorial) so I can have a look on it?

Best regards,
Catalin

Hi, I am building a function for excel and using it via excel dna. The special thing is that it automatically builds .xll file and it is different from vsto. project addin.
look in the registry It will no longer to using .vsto | vstolocal.
how do i sign up for .xll.
It did not load automatically

Hello and welcome to our forums,

I am afraid we do not have experience with the addin type you are currently building so I have no insights about how you could successfully install and register it.

I would suggest you to search for this info in the documentation of the API you are currently using.

All the best,
Daniel

keithrowe wrote: ↑

Wed Dec 04, 2019 6:45 pm

Thank you for this tutorial, Catalin. It was very helpful.

Is there a reason you didn't use the Office "Bitness" registry setting to check the bitness of the installation?

I found this other article on this that seems to work for me. Are there cases where it won't?

keith.

I had the same question Keith and according to this StackOverflow question, that key is not 100% reliable. I think Catalin's solution is very elegant and fool proof.

Thank you so much for this Catalin. I have tested with a PowerPoint application add-in (.ppam) and it works as expected. With this type of add-in, the use of the Project Wizard is different or not required.

Thank you very much for your feedback on this and for your kind words, Jamie!

I am really glad this was of help for you.

Kind regards,
Catalin

Hi,

it is almost perfect, it's not working for Office 2019 and VS 2019


Mick

Hello Mick,

Thank you for your feedback on this.

I am sorry to hear that it is not working. I have answered your other forum thread here:

Import Visual Studio Project Exception calling

Hopefully, we will be able to make this work together.

Best regards,
Catalin

Hi all,

I created Word add-in by selecting project template in VS 2019. I have followed mentioned steps to create aip file for that word add-in, but I do not see any projects getting listed when I select solution. I have attached screenshots as reference. Any help would be appreciated.

Thanks,
Viral Shah

Hello Viral,

This is quite strange, indeed.

Is the solution built on your machine? If not, could you please build it from VS and perform the steps once again?

Additionally, does this work as expected with the files I have provided at the bottom of the main thread?

Best regards,
Catalin