Setup Project

Visual Studio 2010
Visual Studio 2008

Several Steps

1) Add the setup project
2) Build the addin solution
3) Add the files
4) Add the registry keys
5) change the installation folder

Visual Studio 2008

Sign the manifest with a certificate
Create a trust relationship with an inclusion list


Before an add-in can be installed you need to make sure that it will have the necessary permissions.
The add-in must have full trust otherwise it will not load.
The VSTO runtime requires that all assemblies have full trust permissions before they can be run.
This typically involved setting up the necessary code access security.
This can either be done manually or by adding an additional SetSecurity project to your solution

Setup Project

Needs to deploy the deployment manifest and application manifest
Right click setup and choose Add > File
browse to the default output folder bin\release
select the two files and click Open
Because you should only be distributing release builds this approach is fine

target platform ?


When you add the project output from your addin to a setup project all the required components are also included.
These dependencies should all be excluded as dependencies and should be added as prerequisites.

Visual Studio 2005 SE

SetSecurity project
Add this project to your solution
Right click on a setup project
View > Custom Actions)
Add it to the 4 actions

Add the Setup Project

Click on the project
Select (File > Add > New Project) to display the "Add New Project" dialog box.
Other Project Types > Setup and Deployment > Setup Project
Change the Name to match your project but with "Setup" appended to the name
If your current project is called MyAddin then change the name to MyAddinSetup
This will add a setup project below and create a solution that contains both these projects

Build the add-in solution

Right click on the MyAddin project, Rebuild

Add the Files

Right click on the MyAddinSetup
Add > Project Output
Select primary output and press OK
This will add the "Primary Output from MyAddin" plus all the necessary dependencies
Manually add the following two files from your addin bin directory
MyAddin\bin\Debug\ MyAddin.vsto
MyAddin\bin\Debug\ MyAddin.dll.manifest
Right click on MyAddinSetup
Add > File
Browse to this location and select the two files.

Add the Registry Keys

Right click on the setup project
View > Registry
Add the following registry keys:
HKEY_CURRENT_USER \ Software \ Microsoft \ Office \ Word \ Addins
Change the "AlwaysCreate" property to True
HKEY_CURRENT_USER \ Software \ Microsoft \ Office \ Word \ Addins \ MyAddIn
Change the DeleteAtUninstall property to True for the MyAddin key
(String) HKEY_CURRENT_USER \ Software \ Microsoft \ Office \ Word \ Addins \ MyAddIn \ Manifest = C:\Program Files\Russell\MyAddin\MyAddin.vsto|vstolocal
(DWord) HKEY_CURRENT_USER \ Software \ Microsoft \ Office \ Word \ Addins \ MyAddIn - LoadBehavior = 3
(String) HKEY_CURRENT_USER \ Software \ Microsoft \ Office \ Word \ Addins \ MyAddIn - FriendlyName = MyAddIn

Change the installation folder

Right click on the MyAddinSetup
View > File System
click on Application Folder and change the DefaultLocation in the properties window
DefaultLocation = [Program FilesFolder] Russell \ MyAddIn

Creating a Setup Project

In Visual Studio 2005 SE when you create an application-level add-in a setup project (and registry entries) are created automatically.
In Visual Studio 2008 the setup project is not included and therefore must be added manually.
In Visual Studio 2008 you will need to create a solution and then add the document level project and a setup project to this solution.

(Other Project Types > Setup and Deployment > Setup Project)

This uses Windows Installer
1) deploy additional components and registry settings
2) user interaction is required
3) allows custom branding of the installation

Setup Project Steps

1) Install the prerequisit components (Office, .NET Framework, VSTO runtime, PIAs)
2) deploy the individual solution components
3) create additional registry entries (application level)
4) apply the necessary trust

You can add dialog boxes that Microsoft provides or you can import your own.

This uses windows installer
Displays an install wizard and adds an entry to Add/Remove Programs which allows you to uninstall and repair the solution.
The setup project is use to create a windows installer (.msi) file that will install your application.

Setup.exe - This bootstrapper program can check for and intall the necessary pre-requisites

  • Wont automatically check that the client has the necessary pre-requisites

  • Wont automatically create the necessary permissions

Setup Project Properties

AddRemoveProgramsIconSpecifies an icon to be displayed in the Add/Remove Programs dialog box on the target computer.
AuthorSpecifies the name of the author of an application or component.
DetectNewerInstalledVersionSpecific whether to check for a newer version of the application before installing. If this is set to true and a higher version number is found then installation will stop.
FriendlyNameSpecifies the public name for a .cab file in a Cab project.
LocalizationSpecifies the locale for string resources and the run-time user interface.
ModuleSignatureSpecifies a unique identifier for a merge module.
ProductCodeThis identifies a particular version of the application. This is up to the developer. If only small changes have been made to the code then a new product code does not need to be assigned.
ProductNameThis is the name that appears on the setup wizard.
RemovePreviousVersionsSpecifies whether the installer will remove previous versions on application during installation. This only works when the version number has been incremented.
RestartWWWServiceSpecifies whether Internet Information Services will be stopped and restarted during installation.
SearchPathSpecifies the path that is used to search for assemblies, files, or merge modules on the development computer.
TitleThis is NOT the name that appears on the setup wizard.
UpgradeCodeThis identifies the application and should never be changed. This is used to identify the upgrade relationship. Installations must share the same upgrade code in order for an upgrade from one to the other to occur.
VersionThis identifies the number of the version. Also commonly referred to as the Product Version. Changing this version number will force a new ProductCode to be generated.

Application Folder
Defaults to [ProgramFilesFolder][Manufacturer]\[ProductName]
changing into [ProgramFilesFolder][Manufacturer]\[Subject] doesn't work - which fields can you use ???

Change Version #.#.# which changes ProductCode
This will not reinstall over the top of a previous version


Version Numbers

Each assembly has a four part version number as part of its assembly.
If either the Major or Minor part of a version number changes then the assembly is no longer compatible with previous versions
Major and Minor - Changes to the major and minor indicate an incompatible change.
Examples would be a change to the types of some method parameters or the removal of a type or method altogether.
Build - Used to distinguish between the daily builds or smaller releases.
This is the number of days since February 1, 2000
Revision - Incremental change reserved when you need to fix a bug, often referred to as the emergency bug fix number.
This is the number of seconds since midnight, divided by 2.

SetUp Project GUIDs

A windows Installer Setup Project contains 3 GUID's
UpgradeCode -
PackageCode - This identifies a particular version of the MSI Installer and should never be reused across builds. It must was always be updated. This is not displayed in the IDE.
ProductCode -

MSI files also include a version number.
If you attempt to install two different versions of the same application without updating the Package Code, Window Installer will tell you that a different version of the application is currently installed and must be uninstalled first.
This makes sense as a package code is meant to identify a particular build.

SetUp Project Options

Package files - Change to None and you just get the .msi files created

Installing with an MSI

Products can only be installed side by side on the same machine if they have a different Product Code.
If they share a product code then only one can be installed on that machine.
Each major new release should have a B>different Product Code but
Each minor release should have the same Product Code to make sure that you do not have two similar products installed on the same machine.
If significant changes are made to a product then the product code should be changed to reflect this.

© 2024 Better Solutions Limited. All Rights Reserved. © 2024 Better Solutions Limited TopPrevNext