Question

with many computers that already had my VSTO ClickOnce plugin installed. I think this was caused by me changing the signing certificate, but at this point the users don't see the plugin in their Add/Remove Programs, and one of the users removed the plugin
from Excel (after uninstalling the plugin) and used the rundll method decribed in the linke above but the plugin still won't install, throwing the same error.

All replies

Is the VSTO ClickOnce application an online-only application or online / offline one?

"mage -cc" command will clear all the online-only ClickOnce application cache, have you tried to also use this command? If this does not help, would you like to also try to temporarily rename the user\AppData\Local\Apps\2.0 folder to see whether you can
install? All ClickOnce applications are installed in a per-user, per-app sub folder here.

Here are some detaied information about the identity issue in this thread:

That didn't help. I should mention my end users install this from a local installer I send them, not from a URL (which seems to be the case covered in the link you sent).

For this test, my end user removed his MS Office installation, removed the 2.0 folder above, reinstalled MS Office and tried reinstalling the VSTO Add-In but it failed with the same identity error message. What else should I try?

Have your user reboot after removing the 2.0 folder and before installing it again. There's a deal with shadow assemblies and so on with VSTO apps, and sometimes the installs are "sticky" where they aren't with regular desktop apps.

Can you explain more about the local installer deal? What is the installation URL for the VSTO add-in? Does it get it from a server or a file share, or is it packaged, and how does that work exactly?

I develop this plugin in VS 2010. I then publish for a CD installation, pointing that publish to a local folder. That creates several files, including a setup.exe and the manifest thing. I then zip it all and send it to the end users. I guess the installation
URL in this case is the file:// URI of the unzipped folder, right?

The VSTO deployment has to have an installation URL filled in. You can't assure that the CD drives for all of your users have the same letter assigned to them. So what are you filling in as the installation URL in the publish page?

The problem you are seeing is a manifestation of that issue. The installation URL is part of the security of the deployment, and used for the source of updates, etc.

Your guy who's seeing multiple ones installed, or it won't let him install it -- you'll need to make sure it's uninstalled, delete the apps\2.0 folder, and reboot. If it still thinks it's installed, you will need to edit the registry and look for the name
of your add-in, and delete all occurrences.