[RESOLVED] VSTO Plugins Being Disabled During Debug
I haven't delved into this one well enough, but then again, I'm not quite sure where to look.
I'm working on developing a VSTO plugin. Word is auto-disabling it. I have to go into the Options and re-enable it, after which it works fine a far as I can see, except that every time I try to test something, Word objects that it's running into problems with the plugin and asks me if I want to disable it.
The thing is that this plugin is as generic as any can get. The plugin is only adding a button onto a menu. Everything else happens when the button is plugged. That means that the ONLY code prior to the button press is the boilerplate methods that MS added to the project (which have no bodies), and this one:
Code:
Protected Overrides Function CreateRibbonExtensibilityObject() As Microsoft.Office.Core.IRibbonExtensibility
Return Globals.Factory.GetRibbonFactory().CreateRibbonManager(New Microsoft.Office.Tools.Ribbon.IRibbonExtension() {New LaunchButton()})
End Function
The launch button has no custom constructor, nor anything in it's Load method, only in it's Click method, so there really is no code that could be causing the plugin to have trouble.
I found one thing that suggested that it might be throwing an exception when there is no document present, so I changed that, but that didn't quite improve the situation (and some people might find it annoying).
Does anybody have any suggestions as to what I should look at next?
Re: Developing VSTO Plugin...which is Auto Disabled
Re: Developing VSTO Plugin...which is Auto Disabled
did you have a look in word options/ privacy management - trust center / parameters of privacy management- trust center
https://www.vbforums.com/images/ieimages/2021/10/34.png
Re: Developing VSTO Plugin...which is Auto Disabled
Yeah, I got into the trust center, but didn't find anything all that interesting. I got in there when dealing with that inability to find a file thread, because I thought that the location might not be trusted (and then I realized it was looking for .vsto rather than .dotx).
I'll look at the other links in a little while.
Re: Developing VSTO Plugin...which is Auto Disabled
Having looked at the first links, I find it hard to believe that's the right way to go. This is happening during development. I saw the other day that MS will disable add-ins that are taking a long time to load. I even found how they define a 'long time', though I forget the exact timings. However, this add-in isn't taking a long time to load, unless it is counting the time taken to attach the debugger. The 'long time' in question is in the vicinity of a second, which is possible depending on when the counting begins. After all, the debugger first has to launch Word, which could take up to a second. If the count also includes whatever happens before (perhaps compiling, then registering in the Registry?) then there will certainly be a second. It's even worse if the counting includes asking me whether I want to disable the plugin, which happens even before Word launches. Add it all up, and it takes more than a second.
However, I wouldn't think that the timing would start counting from the time I hit F5, I would think it shouldn't start counting until when Word starts to load, and probably not till after that, since it would be absurd to penalize add-in makers if Word itself took a long time to start up.
As for the plugin itself, it's so trivial that it just can't take long.
Interestingly, it kind of does act like this is a timing thing. Word didn't disable the plugin the first time I tried it today, and only told me that it was causing problems and asked me to disable it after that first try. Perhaps MS really IS timing the debug process, and including that in the total time that a plugin incurs?
Re: Developing VSTO Plugin...which is Auto Disabled
It just keeps getting weirder. I have now run the plugin half a dozen times without any messages or disabling happening. I didn't change anything important, either, I've just been tinkering with what happens after the button gets clicked.
That's making it look more and more like MS starts counting from the time VS launches the debug session, and I get penalized for the extra overhead that debugging incurs. In a way, that seems wrong....in another way, that seems TOTALLY an MS thing to do.
Re: Developing VSTO Plugin...which is Auto Disabled
I wrote VSTO for Outlook (in.NET), and had the same problem sometimes.
I think it is when an update is installed by MS, but not sure
my VSTO is combined with a6 app (comunication between with IPC), and when users starts the app, I setup regsitry with the following code
Code:
Dim oRegistry As class_Registry
3 Set oRegistry = New class_Registry
Dim oValues() As String
Dim nValues As Long
Dim nOutlook As Long
Dim nI As Long
4 With oRegistry
5 For nOutlook = 11 To 18
6 .ClassKey = HKEY_CURRENT_USER
7 .SectionKey = "Software\Microsoft\Office\" & nOutlook & ".0\Outlook\Resiliency\DoNotDisableAddinList"
8 .ValueKey = "theapp.Connect"
9 If .KeyExists() Then
10 .ValueType = REG_DWORD
11 .Value = "1"
12 End If
13 .ClassKey = HKEY_CURRENT_USER
14 .SectionKey = "Software\Microsoft\Office\" & nOutlook & ".0\Outlook\Resiliency\CrashingAddinList"
' *** First decrypt all values
15 Call .EnumerateValues(oValues, nValues)
' *** Decrypt all values
16 For nI = 1 To nValues
17 .ValueKey = oValues(nI)
18 .ValueType = REG_SZ
19 If InStr(.Value, "theapp") > 0 Then
20 .DeleteValue
21 End If
22 Next
23 Next
24 End With
Re: Developing VSTO Plugin...which is Auto Disabled
If I understand it right, the general approach that the links and that code are taking is to stop MS from disabling plugins, largely because MS is a little over-zealous about disabling plugins.
That is sounding pretty correct, to me. This issue has simply evaporated, yet I did nothing that could have caused it to evaporate, so I suspect it will be showing up again, periodically.
Re: Developing VSTO Plugin...which is Auto Disabled
Quote:
Originally Posted by
Shaggy Hiker
This issue has simply evaporated, yet I did nothing that could have caused it to evaporate, so I suspect it will be showing up again, periodically.
Sounds about right regarding Microsoft :D
... or check if that Computer has renamed itself to Skynet......
Re: Developing VSTO Plugin...which is Auto Disabled
Well, that's always a possibility. The problem is, though, that it certainly wouldn't admit to it.
Re: Developing VSTO Plugin...which is Auto Disabled
Just to put a conclusion on this thread:
After several days of playing around with this, I have concluded that it's nothing more than an accidental nuisance. I have now run the plugin several dozen times over the course of debugging. Most of the time, I am not offered the chance to disable the plugin that I am currently debugging, but there are times when I do. The most notable time is when something went wrong with the debugging test. If the app hung, or I broke out of it for some reason, then I will surely be asked if I want to disable the plugin the next time I run it, even though I was the root cause of the plugin causing trouble.
So, MS is just being overly sensitive about the performance of plugins. I can understand that. If a plugin takes too long, or misbehaves, people will tend to blame MS, when it wasn't their fault, so they are noting issues with plugins and offering to disable them (or just doing so automatically). They didn't make an exception for debugging, and they probably couldn't. VS is launching Word, in my case, so Word is doing what Word will do. It doesn't know that it was launched from VS, or that the plugin that it is loading is being debugged, it is just running....and the plugin is misbehaving, so it is doing what it's supposed to do with a misbehaving plugin.
It's unfortunate, but understandable.
