Why we should NOT run .vsto-installer manually

I assume you all sometimes have experienced issues regarding MailLink and missing addins for Outlook and OfficeRibbons.

And I also guess someone has been tempted to manually run the .vsto-installers to try to solve the problem(s).

There has been discussions regarding this and some think this is the solution.

From R&D this has never been an option and we do not support this operation.

Below you can read why this is not a good option.

In theory, opening a VSTO file will trigger the Microsoft VSTO Office Addin installer, it does its job, and everyone lives to be happy ever after. In practice, things are never quite that simple.

What the VSTO actually installer does are the following thing:

• Verifies the syntax and contents of the VSTO file (application manifest) and checks its cryptographic signature.
• Does the same to the deployment-manifest referenced in the VSTO file.
• Verifies that all files referenced in the deployment manifest exists and that the cryptographic hash/signature the file has in the deployment manifest matches the actual file.
• If all this is OK, it may attempt to copy the files referenced in the deployment manifest to a user-owned location.
• Once all this is done, it adds a registry key to the user’s registry-hive with a reference to the newly created copy/deployment and not the original location.
• The newly installed version will reference the VSTO file without correct runtime-flags as set by our installer.

There are several problems with this:

• Depending on SuperOffice version, not all files referenced in the deployment manifest may exist as some are actually only needed build-time. This can cause the deployment to fail, and the existing (good) installation to be corrupted.
• If deployment succeeds and a new copy is created, outside the SuperOffice installers control, there is no longer any guarantee that a uninstall will correctly clean the users machine.
• Similarly with upgrades, only the “central” deployment in C:\program files is upgraded, but the user may be stuck on old version in their AppData folder, which may or may not be incompatible.
• Because of missing runtime flags, every time an Office app is launched, a shadow copy will be created of the deployed application.
  • This can at best cause performance issues. These issues will be amplified by use of roaming profiles and anti-virus.
  • This can at worst cause issues with DLL-references and other file-dependencies, because we expect to be running inside of “Program Files” (and only there). Without correct runtime flags we may find ourselves in a pseudo-random C:\users\<user>\AppData\LocalLow\ShadowStorage\74897489237489234\23423423\423423\4234.
    On a per dll basis.

In short if you try to “fix” a Ribbon or MailLink-issue by running the VSTO file manually, you must know that there are no guarantee from RnD that the configuration you are deploying at the customer will work and that it has never been tested and never will.

If you do this, you are much more likely to create future support issues much bigger than those you have now. If you do this systematically, you are systematically tampering with our ability to conduct upgrades at all.

All bets are off if this will work now or for any installation in the future.

I think we can agree that this is not an acceptable risk to take.