Visual Studio 2010
Visual Studio 2008
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
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
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
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
|AddRemoveProgramsIcon||Specifies an icon to be displayed in the Add/Remove Programs dialog box on the target computer.|
|Author||Specifies the name of the author of an application or component.|
|DetectNewerInstalledVersion||Specific 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.|
|FriendlyName||Specifies the public name for a .cab file in a Cab project.|
|Localization||Specifies the locale for string resources and the run-time user interface.|
|ModuleSignature||Specifies a unique identifier for a merge module.|
|ProductCode||This 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.|
|ProductName||This is the name that appears on the setup wizard.|
|RemovePreviousVersions||Specifies whether the installer will remove previous versions on application during installation. This only works when the version number has been incremented.|
|RestartWWWService||Specifies whether Internet Information Services will be stopped and restarted during installation.|
|SearchPath||Specifies the path that is used to search for assemblies, files, or merge modules on the development computer.|
|Title||This is NOT the name that appears on the setup wizard.|
|UpgradeCode||This 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.|
|Version||This 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.|
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
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
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.
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.
© 2019 Better Solutions Limited. All Rights Reserved. © 2019 Better Solutions Limited TopPrevNext