I developed a VSTO
Word
add in
in VS 2017 Pro. Works fine, ready to deploy. However, I cannot find a working procedure for packaging my VSTO
Word
add in
for use on machines other than my development machine. For any particular machine , I need to deploy it once and have it available for any user who may login using their account.
First came across this, but it involves using InstallShield Limited Edition which, apparently is no longer available for VS 2017.
Tried this but it a few of its steps seem to be missing parts or say "do x" without explaining how.
Tried 'InnoSetup' and the 'bovendor/VstoAddinInstaller', but following the 'bovendor' procedure results in the 'Innosetup' compiler throwing an error (a bovender-dictated stanza is missing a required element). Can't get a response from bovendor.
Searched Microsoft
docs and just can't find a procedure. Can anyone provide the procedure for packaging a VSTO Word add in for deployment?
Update Successfully packaged and deployed my add-in using the WiX tool set. See my answer below
I usually use the Click-Once deployment within Visual Studio. You can deploy it to a network path so other users will be able to install it.
First you want to create a non-expiring certificate for Visual Studio projects
Type
Developer Command
in the Start Menu search and right click and select Run as administratorPaste the following commands in the command prompt for MakeCert and pvk2pfx
Note:
MM/DD/YYYY
-f
parameter can be used at the end of the pvk2pfx line for overwriting an existing fileAfter the password prompt, you'll need to run the second command line by just pressing the Enter key.
Now you can select the same certificate for multiple Visual Studio projects
In the Visual Studio project properties, select Signing* click on Select from File…. Navigate to the same path from the command prompt and select the certificate file (*.pfx)
Publish the project
Then go to the Publish tab in the project properties and click Publish Now. It will create a executable file in the published location. Then you just need to send a link to the
.exe
file to your end-users.Update (11/26/2019): If your setup uses 64-bit Office, see How do you package a VSTO Word addin for deployment to a 64-bit Windows 10 machine running Microsoft Office 64 bit using WIX?
Successfully packaged and deployed my
add-in
using theWiX
tool setCredit: I learned most of this using Pieter van der Westhuizen's example on the Add-in Express Blog.
I used
Visual Studio Pro 2017
,.NET 4.6.1
, andC#
on my development machine (64-bit) to implement myVSTO
Word
add-in.My requirement is to deploy the
add-in
once to a 64-bit production machine (i.e., a Citrix virtual desktop master image) so it's available to any user who logs onto the production machine (i.e., logs on to a virtual desktop based on the master image). The 32-bit version of Word 2013 is installed on the master image.As I understand it, this means the 'add-in' has to be installed under 'C:\Program Files (x86)' for two reasons:
Also, because all users need to access the
add-in
, the requiredVSTO
registry key settings go under the rootHKLM
(and notHKCU
). Essentially, this 'all users' setup is the opposite of the 'one user'Click-Once
setup. Apropos of nothing, I'm in an enclave that is not connected to the Internet. So, all software I use is downloaded elsewhere, and then carried into the enclave and installed locally.The release files for my
VSTO
word add-in (i.e, inC:\....\Visual Studio 2017\Projects\FooAddIn\FooAddIn\bin\Release
) are:What I did
Downloaded and installed 'WiX' v3.11.1 onto my development machine from http://wixtoolset.org/releases/.
Downloaded and installed 'Wix Toolset Visual Studio 2017 Extension' onto my development machine from https://marketplace.visualstudio.com/items?itemName=RobMensching.WixToolsetVisualStudio2017Extension
Opened my
add-in
projectFooAddIn
usingVS 2017
and inSolution Explorer
, right-mouse clicked on the top-lineSolution
node and clickedAdd -> New Project
.In the
Add New Project
dialog, clicked onv3
underWiX Toolset
and then clicked onSetup Project for WiX v3
. I named the new projectFooAddInSetup
. Visual StudioSolution Explorer
showsSolution FooAddIn (2 projects)
, projectFooAddIn
, and projectFooAddInSetup
.Under
FooAddInSetup -> References
, added references toC:\Program Files (x86)\WiX Toolset v3.11\bin\WixNetFxExtension.dll
andC:\Program Files (x86)\WiX Toolset v3.11\bin\WixUIExtension.dll
(These are needed by elements of the Product.wxs file to build the installer).Configured VS to also build the setup program: In VS, click on Build -> Configuration Manager. In the Configuration Manager dialog, checked the
Build
check box for FooAddInSetup.Created
EULA.rtf
(mine says "This is license-free software") and placed it in C:....\Visual Studio 2017\Projects\FooAddIn\FooAddInSetupCreated a preprocessor variable for the path to the location of my
VSTO
release files: In Solution Explorer, right mouse clickedFooAddInSetup -> Properties
. On the FooAddInSetup tab, Clicked on 'Build'. In theGeneral
section, clickedDefine 'Debug' preprocessor variable
. In theDefine preprocessor variables:
textbox, enteredAddinFiles=..\FooAddIn\bin\$(Configuration)\
Populated the boilerplate
WiX
Product.wxs
file for myadd-in
as shown below under Product.wxs fileNote: In the
wxs
file, I modified theVisual Studio 2010 Tools for Office Runtime
hyperlink in theCondition
element - the one in Pieter's example is dead.I set the Solution Configuration to
Release
and built the solution.Copied
FooAddInSetup.msi
from...\FooAddInSetup\bin\release
on my dev machine to my production machine (the VDI master) and ran the setup program as admin.Results
Without regard to the registry settings I asserted in the
wxs
file, my registry keys were created inHKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Office\Word\AddIns\LesCaveatAddIn
, i.e., they went into HKLM as expected, but they went into\Software\Wow6432Node\Microsoft.....
instead of\Software\Microsoft....
as I coded in thewxs
file. I assume this is because my production machine is a 64-bit machine.As expected, the add-in itself was installed under c:\program files (x86)
Brought up Word, and the add-in was loaded as expected
Product.wxs file