How to re-add a deleted VSTO Add-In - ms-word

I've got a strange issue with a Word VSTO add-in on one machine where running the visual studio project opens word but does not attempt to start the add in as far as I can tell.
I got to this point because I accidentally clicked Remove for the Add-in on the Manage COM Add-ins page, instead of re-enabling it after a failure.
I want to know how to re-enable a deleted add-in - I'm thinking that perhaps there is a registry key somewhere I need to get rid of.
When I run the project from Visual Studio it does not attempt to
start up at all, Word starts instantly with no "something-is-failing"
type pause.
No breakpoints in ThisAddIn_Startup are hit.
In Word : File/Options/Add-ins - the add-in does not appear under Inactive or Disabled Addins
Word : Manage COM Add-ins Go... it does not appear.
Word : Manage Disabled Items Go... is empty.
I've tried installing and uninstalling the published version, to see if that wakes anything up, and I've tried changing the path of the VS project, just in case that makes a difference (and various restarts, cleans, rebuilds, locally deleting and re-cloning from git etc) but I can't find a way to get this to work again. On a different machine, cloning the add-in from Git and opening it in Visual Studio and its all fine.
I've tried re-adding via the select DLL (or select .) dialog on the COM Add-ins but nothing I select appears to be a valid add-in.
Any help to figure out how to get back to a working development environment would be appreciated.
EDIT
There's a lot going on below - so I thought I'd clarify that the successful solution was the online-repair of Office

What is the LoadBehaviour in the registry? It should be 3...
To find out, look in
32bit Word => Root\Software\Microsoft\Office\Word\Addins\add-in ID
64bit Word => Root\Software\Wow6432Node\Microsoft\Office\Word\Addins\add-in ID
where Root is HKEY_CURRENT_USER or HKEY_LOCAL_MACHINE, depending on whether the addin is installed for current user or everyone.
If the value for LoadBehaviour is not 3, then change it to 3 and restart Word.
Here is the Microsoft docs about it: Registry entries for VSTO Add-ins
If it still does not work, try to re-enable as it might be hard disabled:
In the Manage box, change COM Add-ins to Disabled Add-ins, and click Go.
Select the add-in and click Enable. Click Close. Now the add-in can be loaded again...
Back in the Manage box, change Disabled Add-ins to COM Add-ins, and then click Go.
Check the checkbox next to the disabled add-in. Click OK.
Here is the Microsoft docs about it: How to: Re-enable a VSTO Add-in that has been disabled
Also, if you haven't done this already, it is worth setting VSTO_SUPPRESSDISPLAYALERTS to 0 as described on this page: How do I enable VSTO error / display alerts?
If none of the above helps, then it is worth doing a Online repair of Office from Add or Remove Programs.

I believe that you need to change the version of the VSTO add-in in order to be able to update it or re-install it. Once an add-in version has been disabled, this is permanent.
See Uninstall MS Word Add-in for details. Let me know if that worked.

The most extreme steps I've had to take when things aren't working as expected are to clear out the VSTA cache, either in the registry or the filesystem. Note that I work with template-based customizations that are attached to documents, not add-ins that are always present, so this may not apply to you. Or maybe it does, I don't know.
Registry
Look for an entry for your add-in under HKCU:\Software\Microsoft\VSTA\Solutions. I use PowerShell for this, and an example command chain would be something like this:
gci "HKCU:\Software\Microsoft\VSTA\Solutions"
Hive: HKEY_CURRENT_USER\Software\Microsoft\VSTA\Solutions
Name Property
---- --------
1234abcd-1234-abcd-1234-abcd12 Url : file:///Z:/path/to/your/addin.vsto
34abcd SubscriptionID : addin.vsto, Culture=neutral, PublicKeyToken=<removed>, processorArchitecture=msil
ApplicationID : file:///Z:/path/to/your/addin.vsto#addin.vsto, Version=<removed>, Culture=neutral,
PublicKeyToken=<removed>, processorArchitecture=msil/addin.dll, Version=<removed>, Culture=neutral, PublicKeyToken=<removed>,
processorArchitecture=msil, type=win32
ProductName : addin
LastCheckedTime : {4, 201, 185, 1...}
UpdateEnabled : 1
UpdateInterval : 1
UpdateIntervalUnits : days
remove-item "HKCU:\Software\Microsoft\VSTA\Solutions\1234abcd-1234-abcd-1234-abcd1234abcd"
Filesystem
My customizations (see note at the start) are installed at %localappdata%\Apps\2.0 and on rare occasions I need to delete them manually. Clearing this one out is less straightforward, but usually there's a single anonymized folder like ABCDEFG0.QWE. I just delete that, and along with the other half of this, I've never run into a problem I couldn't solve. FYI if you have multiple deployments this might uninstall all of them. I don't do it very often so I'm not 100% familiar with how this area works, but I've never made anything worse by doing this.
I don't know how this differs, if at all, for application-level add-ins, that can be installed to Program Files.
Edit: adding some relevant links.
How do I completely uninstall a ClickOnce application from my computer?
Clear the .NET-downloaded application cache without Mage?

I faced the same problem. At first I deleted the corresponding registry key for the addin (The registry path can be found in the other answers). After that I tried Build > Clean Solution and after that Rebuild Solution. That solved the issue.

Related

How to deploy an Office VSTO add-in using Visual Studio 2017

I've created an Outlook add-in, debugged and works fine. I want to be able to package it up for distribution. This is for a very limited audience 5-10 people. What are the steps to doing so?
I tried Build | Publish which appears to work (using options of local filename and CDROM install location), but creates a massive 1.5MB setup.exe file and when it is executed, takes forever (it appears trying to contact some remote server and times out and pops an error, although the add-in appears to be registered).
Looking online, I found references to creating a SetupProject or using InstallShield Limited addition, but none of those appear to apply to Visual Studio 2017.
I'd be happy if I could just provide my DLL and a .reg file -- this is for a small set of 5-10 power users.
What is the simplest way to deploy this add-in?
The easiest way is Build | Publish. Just disable any online activities if you don't want it. You can do that in Project -> Settings -> Publish. Check your "Updates" settings for example.
You can download a Visual Studio project type from here:
https://marketplace.visualstudio.com/items?itemName=VisualStudioProductTeam.MicrosoftVisualStudio2017InstallerProjects
This will allow you to deploy the package, but it's somewhat buggy in my opinion. Also, the link above does not have any documentation. You have to go to another page for that and the answer is buried in the comments:
https://msdn.microsoft.com/en-us/library/ybshs20f(v=vs.90).aspx
The ClickOnce has worked more consistently for us, however. Just right-click and select Publish on the Project.
It is a long ways off from the old InstallShield LE process, which allowed you to customize the entire process including images, click-through licensing, etc.
But the InstallShield LE had it's own set of issues, and seems to have been all but abandoned.
It may be worth looking at other 3rd-party tools like WiX (http://wixtoolset.org/) to get things installed correctly, or even manually writing your own installer to get things put where they need to be.

Update Target Button is disabled in Sql Server Database Schema Comparison

I use Visual Studio 2013 Professional Update 4 in combination with multiple SQL Server 2012 Enterprise servers/instances. The Idea was to create a Version controlled deployment using a Visual Studio Solution with SQL Server Projects.
However for some reason the "Update Target" and "Generate Script" button is disabled.
I can update the local database project from the sql server database but the other way around is not working. (see screenshot)
Google is not helpful at all although I found a few people with a similar problem.
Update target button is disabled after schema comparison
VS2012: Schema compare, update button disabled
VS2012 Schema compare buttons disabled
But none of this questions/blogposts is about Visual Studio 2013 and in addition none of the proposed solutions is working for me.
Question: Why is the Update Target button disabled and what do I have to change to fix this?
Note: Of course, I'm using the latest version of SQL Server Data Tools(12.0.50318.0)
This was driving me nuts, as well. I finally noticed a "warning" message stating "Cannot generate deployment plan due to an internal error". Because of this, the Update and Generate Script buttons were both disabled.
I resolved this by closing Visual Studio, navigating to the folder containing the Database project and removing all (*.dbmdl) files. I then restarted Visual Studio, re-ran the compare schema and the Update button was enabled.
The tip that helped me was to look at the error list. (View Menu, Error List). Once I cleared the errors (just the errors, the ones with the red X) I was able to compare the schema again and the Update and Generate Scripts buttons were both enabled.
Beside the generate script, click on OPTIONS and select only the objects for which you want to compare.
This and ONLY this worked for me.

Error when opening Word document that was created by VSTO Template

I have created a new Visual Studio Word 2010 Template project, now I want to deploy it using a Windows Installer setup.
I followed this tutorial using Visual Studio 2012 with InstallShield 2013LE.
After installing the setup and opening the Word Template, it seems to work fine. However, after saving the template as *.dotx-document and opening it again the Installing Office customization dialog appears.
The message says There was an error during installation: Downloading file file:///[Path to the dotx file]/WordTemplate.vsto did not succeed.
To check whether I've made an error creating the setup and registry entries, I also tried Advanced Installer 10.9 Office Add-In setup, that creates the required entries automatically. It also fails with the same error message.
There is nothing special about the VSTO Addin. I started a new project for testing purposes, that adds a ribbon and a header to the Word Template file.
Finally I tried the built in Click-Once installer, with success, newly created documents can be opened without any exception. But it comes with some limitations. I would like to add some files and let the user choose the installation path, what doesn't seem possible.
So what am I missing to deploy my VSTO AddIn?
I believe that such a problem is coming from proxy server issues. The proxy server on the client machine is blocking the download of your vsto file that is considered as an executable file.Unfortunately the only solution I see was stipulated in an old post proposing to zip your installer and to send it to users ( which is not optimal, I must agree).
You must also run a command to clear the app cache any time you deploy (from your windows console):
rundll32 dfshim CleanOnlineAppCache
Hope that helps !

MSI, Repair runs but I don't know why

I have an MSI package I maintain with Installshield 2012 Pro.
The package was created a few years again and requires periodic maintenance as new versions of the application is installs are released by our development team. This MSI has been used in many locations, on many machines without issue.
At one customer location, they've install about 20 copies of the application on 20 machines. Each machine is built exactly the same.
Periodically, for an unknown reason registry entries relating to that application go missing. Not all of them, a select one or two... the same entries always go missing.
We so far have failed to track the exact root cause, however one of our support engineers noticed the MSI repair dialogue appearing when they opened the application shortcut. Following this, the registry entries went missing.
On each instance of the registry entries going missing we have removed the MSI from the c:\Windows\Installer directory. On machines we've made this change too, the registry changes so far have not disappeared again.
This leads me to think the MSI is somehow removing the selected registry entries during the repair, but I don't understand how.
There are at least 50 registry entries under the same key as the entries that get removed. (these are created by the application not the installer)
The MSI package doesn't insert any keys at all during install
There are no custom actions at all
I only have one key file set in the whole MSI, and this is for a component installed in Windows\system32
None of the shortcuts are 'Advertised'
There appears to be a clear link between removing the MSI from the Installer directory and no further occurrences, but I fail to see what in my MSI could cause specific registry keys to disappear.
I realize the exact reason this this is subjective to my MSI or the customers systems, so as generally as possible I ask:
Why would Windows launch the MSI repair function, considering the above
Can an MSI alter the registry, considering the above
Is there anyway post installation of an MSI to disable the auto repair function for this MSI?
How should I alter the MSI to ensure auto repair doesn't occur?
Thanks
Start by proving whether the auto repair is related to your product. Check the application event logs for the component id that caused Windows Installer to kick off the auto repair. Then, if it's part of your installer, figure out why.
It seems unlikely that your MSI would alter the registry. Although you do not specifically say there are no RemoveRegistry table entries, it's hard to imagine any snuck in accidentally.
There are only bad ways to disable auto repair (some global, some involving not registering your installer). Avoid them.
First figure out what's wrong. Then figure out how to fix it. For instance if in step 1 you determine the component triggering auto repair is part of your install, perhaps set the logging policy on a machine where this occurs so you can get a verbose MSI log.

Is it possible to load an instance of a VSTO addin from a network drive?

I've got a VSTO 3.0 Word Addin. Around here, they do all work off network drives (for backup reasons, etc etc).
Anyway, when I'm in the IDE, I can run my project, it automatically starts Word, i can debug, break, etc, just fine.
HOWEVER... If I compile the project, then run Word OUTSIDE of the ide, the Addin registry entry is, of course, still pointing to the NETWORK copy of the VSTO dll, not a local machine (C Drive) copy, and the addin always fails to load.
I can copy the DLL down to the local machine, update the registry to point to the C: location, and then run word and it loads fine.
But I was wondering if there's any way to config VSTO to be able to load an addin from a network share directly.
I've tried setting the "TRUSTED LOCATIONS" in Word 2010 to point to my network location, but it didn't help.
The only oddity in doing so is that the error message I get back from Word when I have VSTO_SUPPRESSDISPLAYALERTS=0, contains a path of file://j:/path/path/path, ie a mapped drive letter.
BUT, when I try to add the j:\path location to my "trusted locations" in word, it always converts it to a full pathspec, ie \domain\dfs\path\path.
I'm wondering if that mismatch is what's screwing it up, but I can't find anyway around it.
Well, as far as I can tell, it's just not possible to load addins on a network drive without running them in the IDE. If someone comes along and knows otherwise, I'd love to know, but I'll go ahead and mark this question closed for now.
Essentially, what I've done is create a little REG script that reregisters the add in to point to the local drive, then, when I need to run as a release (ie NOT in the VS IDE), I compile, copy the dll down locally, and run the regscript. Not great, but not too bad either.
See the registry key to enable VSTO 4 loading of network add-ins here: Installing VSTO 4.0 Causes VSTO 3.0 Addin to quit working