0

As it es really hard to get some good explanations for deploy and update VSTO AddIns, I could not find an answer to this problem.

I have a VSTO Excel AddIn, written in C#. I deploy it on a UNC-path and the users install from there. The publishing folder and the installation folder are pointing to the same UNC path. The update mode is set to "Every time the customization runs".

The installation as well as the add in is working well. However, if I publish an update to the UNC path, the user gets informed that, it is not possible to install that add in, due to the fact, that it's already installed. The user should uninstall the old version and afterwards install the new one.

Is there an option to overcome that issue? Something like just hit update and the user gets the new version?

BR Jonas

Jonas
  • 157
  • 1
  • 1
  • 6
  • The only time I see this issue is when a non-UNC path is used at some point. I assume at the initial time of install. Do they have it mapped to a drive? – Chris Jul 19 '19 at 20:17
  • The Initial Installation works properly. It's only occuring, if I push a new Version to the path. Regarding the mapping, normally it's not mapped. Should it? – Jonas Jul 20 '19 at 07:30
  • It only matters that it's updated using the same path mechanism each time. So if a user installs it from e.g. G:\path\to\your.vsto, but it tries to update from \\path\to\your.vsto it won't work. Or vice versa. The update path you set in VS can only be UNC which leads me to believe your users have it mapped to a drive and probably installed from there. You can tell if you dig into the registry. – Chris Jul 21 '19 at 15:57
  • It's deployed with a FQN of the share (\\Server\Share). The publishing folder as well as the installation folder. So that shouldn't be the problem, right? – Jonas Jul 22 '19 at 06:44
  • That doesn't rule it out, no. The path you deploy to is not necessarily the path users access it from. They can open up an explorer window using a mapped drive and install it that way, and it will cause the problem you're seeing. Run `Get-ChildItem 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Uninstall\'` with PowerShell, see what's in the registry. – Chris Jul 22 '19 at 11:49
  • Okay, thats clear. However, I tested it on my local machine and accessed the path via FQN UNC (The drive is not even mapped) and faced the same problem....Is my intend even possible? – Jonas Jul 22 '19 at 11:55
  • The UninstallString in regestry is UninstallString: c:\Program Files\Common Files\Microsoft Shared\VSTO\10.0\VSTOInstaller.exe /Uninstall file://server/1_Folder%20Name/Test/ProgramName.vsto UrlUpdateInfo: file://server/1_Folder Name/Test/ProgramName.vsto – Jonas Jul 22 '19 at 12:06
  • Yes, it's possible, and that looks fine to me. Nothing is immediately coming to mind as to what else could be wrong. – Chris Jul 22 '19 at 12:21
  • Hm, if I run "c:\Program Files\Common Files\Microsoft Shared\VSTO\10.0\VSTOInstaller.exe" /Uninstall file://server/1_Folder%20Name/Test/ProgramName.vsto it runs properly and uninstalls the program.....Strange – Jonas Jul 22 '19 at 12:29
  • You substituted the server name, was the real value the same value you expected? E.g. \\server.domain.com\ vs a shortened name like \\server\. I know you mentioned FQN so I'm guessing it was, but seems worth asking. – Chris Jul 22 '19 at 14:36
  • Yes, it's the FQN server.domain.com – Jonas Jul 22 '19 at 14:56
  • When you tried it on your dev machine today, were you careful to avoid [this issue](https://stackoverflow.com/questions/39798538/clickonce-automatic-update-error-for-vsto-add-in-for-excel)? I often forget about it. Building it in VS messes with what's currently installed. – Chris Jul 22 '19 at 16:21
  • Cant believe it...The problem is in fact only present on my machine. So your link works :) – Jonas Jul 23 '19 at 08:43
  • Great!. I've provided a summary of what we talked about in an answer. – Chris Jul 23 '19 at 12:48

1 Answers1

0
  1. The path used when users access it must be the same as the update path.
  2. When running on your dev machine, you should be aware that building in VS interferes with install/upgrade logic.
Chris
  • 3,400
  • 1
  • 27
  • 41