I built an extensibility addin using the wizard in VS-2003 for Microsoft Word. When installed, it adds over 10 seconds to Word's startup time. Does anyone have any ideas on why this is happening The Excel addin I created does not have this problem.
The delay appears to come before the OnConnection sub is called. CPU usage is 0% during this delay.
It's difficult to say without seeing your OnConnection method...
Could you take timestamps at the start and end of the OnConnection method, substract them and show in a messagebox to confirm that your OnConnection method is taking 10 seconds
If so, then you need to profile more carefully the code inside. If not, then you need to use tools like http://msmvps.com/blogs/carlosq/archive/2006/11/16/tools-for-the-toolset-of-add-in-developers.aspx to spy file and registry activity to guess what's going on...
The delay actually comes before the OnConnection sub is called.
I was able to narrow down the problem. The delay only occurs when my ethernet connection is active. I have no clue where to go from here though. How could my ethernet connection affect my Word AddIn
Moving to the VSTO forum, the VS Extensibility forum is for programming the VS extensibility model.
Craig
Hello J-Man,
sometimes this comes from the location of your Normal.Dot or - e.g. if you open a .doc file wich have a template associated that has it's location on a networkshare wich you won't have. So word tries to open the template and here comes the delay.
This is also a known issue.
Hope this helps,
greets, Helmut
Carlos,
Thanks for the link to the process monitor. It tracks a lot of information, so hopefully over time I can narrow down my problem. I did a new time study and found that the delay occurs after the Connect class is created, but before the first line is called in the OnConnection sub.
Hi J-Man,
Unfortunately, any help I can give you at this point is largely guesswork. If you can identify which module is present at the top of the callstack (ie, Word, or some other file), we might be able to guess at what's causing the problem. At the moment, Helmut's guess is where I would go as well; a network-template reference would potentially cause a slow down.
If the delay happens AFTER your Connect class is constructed and before OnConnection is called, it's a true oddity. The CLR has already been loaded and started, as has your files.
The two operations happen sequentially for your AddIn -- no other AddIn should be called in the intervening time frame -- and I'm not noting anything that leaps out as "this can take a long time." I would be very interested to see what seems to be delaying the process so greatly -- do you have macros on your template Is your template network enabled
If you can repro on another machine, it would be very valuable. At the moment, we have to make guesses as to what might be "peculiar" about your particular machine.
Thanks,
Andrew
Andrew,
As far as I know there are no network templates or addins. Everything is installed and runs locally. Also, my addin makes no network references and the entire project is written in vb.net, so there are no vba macros. The addin creates a toolbar with custom buttons and functions.
I was able to narrow it down to the ntuser.dat file. If if delete it (not a suitable option) the problem goes away. So the problem lies somewhere in the user registry. I tried deleting the entire "Office" key but that did not effect anything. It appears that a non-office related setting is causing the problem.
I'll keep pecking away at this and see what I come up with. I'd like to find a solution to this before I have the rest of the office install the addin. I had someone else volunteer to be a beta tester and he hasn't had any problems thus far. Hopefully this will just be a problem on my user profile.
Thanks for the input,
J-Man
I found out that the problem goes away if I uncheck "Automatically detect settings" in internet explorer.
Any ideas on why this would affect my addin
Hi J-Man,
I'm glad you figured out the cause. I just wish I had some information to give you.
This forum is primarily for VSTO; the Shared Add-In wizard doesn't rely on the VSTO deployment system, so any guidance I can offer is really restricted to a small chunk of code. Does this happen with an "Empty" project as well
Even if your VB.Net Add-in doesn't refer to VBA, if there is macro code in your normal.dot file, it may be affecting load performance if it makes calls to the network.
It's a long shot, but something is definitely trying to use the internet; VBA is the likely suspect, but it could be a taskpane, or a smart tag that attempts to access the internet. The CLR code related to the AddIn won't try to access the internet, nor will the application itself. If this problem is visible on other people's machines, I would hazard the same cause. Unfortunately, it's not anything we can really support. Best I can find may be some relation to Outlook and Information Rights Management not being properly configured or issues with the certificate revocation list for signed controls -- but the former doesn't appear related and the latter would be a delay BEFORE your control is instantiated; unfortunately, neither provides much to go on.
I would recommend clearing everything else from Word on your machine -- no Smart Tags, turn off Autocorrect, etc. -- and see if the problem repros with just your addin. If not, slowly add the components on your machine back until you find the "bad" one. Based on everything you've said, both your solution and Word are more or less in the clear. Hopefully you can isolate an individual component which is causing the slowdown.
I hope you find whatever is causing the slowdown, but I'm glad your solution isn't to blame.
Andrew
I wonder whether this is related to the verification of digital signatures revocation.
Basically, Primary Interop Assemblies are signed with digital signature. When assemblies are loaded, CLR collects evidences about the assemblies and, in particular, it verifies the digital signatures. Verification involves contacting the publisher's CRL (certificate revocation list) and hence attempts to establish an internet connection. You can disable this behavior by unchecking the corresponding option in IE - Tools -> Options -> Advances tab -> Security group -> Check for publisher's certificat revocation.
Founds this link on the issue:
One issue that can cause this problem is that if the server does not have access to the internet, then the .NET framework can't access the crl.microsoft.com website to verify that the digital signatures used to sign the binaries for managed applications are valid. Each certificate check has a 15 second timeout in the .NET runtime implementation. Depending on what features are installed, this can add up to a minute of startup time for Management Studio.
There are a couple workarounds:
1) Configure a proxy server to allow access to http://crl.microsoft.com from your server
2) Configure your firewall to return a failure status quickly when it blocks access to the http://crl.microsoft.com website
3) Disable checks for certificate revocation. You can do this using Internet Explorer by opening the Internet Options dialog, going to the Advanced Page, and then un-checking the "Check for publisher's certificate revocation" checkbox. There are fraudulently signed binaries in the wild that can make virus-infected applications look like they were published by Microsoft. Disabling this check should probably not be done on machines with internet access.
Hi J-Man,
Misha and I discussed this offline; if the problems don't occur in your Excel solution, and it, too, has used references to Excel, then the CRL list is likely not the culprit. If your Excel Add-in, however, was "blank," then it could be to blame.
It looked good, for a moment there.
Thanks,
Andrew
Misha and Andrew,
When I disable the check for certificate revocation option in IE, that also gets rid of the delay. But what doesn't make sense is that I can reproduce this error on two seperate computers (work and home) and there is no outbound firewall on either. Nothing is blocking the Framework from accessing crl.microsoft.com.
Also, I had someone else install the addin at work and everything works flawlessly regardless of the IE options selected.
With regards to Andrew's comment, my Word addin is seperate from my Excel addin, but both were created initially using the shared addin wizard and both get installed with the same setup project.
Thanks,
J-Man
Hello J-Man,
can you try to use a Networkmonitor / sniffer to see what your AddIn want's to access from Internet
Maybe this could give us a hint in wich direction we have to look.
Greets, Helmut