C
Christine
I've been working on an add-in for MS Word. It started as an extensibility
"shared add-in" project in VisualStudio.NET 2003, so it's managed code,
VisualBasic.NET.
Recently, I added some new code that was throwing exceptions, so I went to
the task manager and killed the Word process in which my DLL was running.
After this, Word (Office Professional 2003) would no longer load that
add-in. Furthermore, if I create a new extensibility project in Visual
Studio, with just a message box in the OnConnection subroutine of the Connect
class, saying "On Connection reached", and build, Visual Studio seems to
create all the right registry entries (I change load behavior to 8, load on
demand in regedit), but the DLL won't load.
In both cases, the DLL will display in a list of COM add-ins for an instance
of Word. When I try to load the DLL through the Word interface, the add-in
load behavior entry in the registry is changed from 8 to 9 (indicating
"connected," as I understand it), but the code in the OnConnection class does
not execute. Furthermore, if I re-open the COM Add-in dialog, the DLL is not
shown as loaded (though, as mentioned earlier, the registry LoadBehavior
value has, at this point, been set to 9).
I tried a new project, same "extensibility" profile, with load-on-start-up
behavior. It failed to load, similarly to the add-ins described above.
Having run reinstall/repair on Visual Studio, Word, Visual Studio Tools for
Office, just to be sure nothing fundamental had gotten broken, I am mystified.
This reminds me a little of how Macros and wlls fail silently to "load on
demand" with high security settings, and I'm wondering if there is a security
issue. Word security is medium and "trust all installed add-ins" and "trust
access to your visual basic project" are checked.
I'm mystified, and haven't been able to find anything in the MSDN knowledge
base or literature.
Can anyone shed some light?
Thank you.
- Christine
"shared add-in" project in VisualStudio.NET 2003, so it's managed code,
VisualBasic.NET.
Recently, I added some new code that was throwing exceptions, so I went to
the task manager and killed the Word process in which my DLL was running.
After this, Word (Office Professional 2003) would no longer load that
add-in. Furthermore, if I create a new extensibility project in Visual
Studio, with just a message box in the OnConnection subroutine of the Connect
class, saying "On Connection reached", and build, Visual Studio seems to
create all the right registry entries (I change load behavior to 8, load on
demand in regedit), but the DLL won't load.
In both cases, the DLL will display in a list of COM add-ins for an instance
of Word. When I try to load the DLL through the Word interface, the add-in
load behavior entry in the registry is changed from 8 to 9 (indicating
"connected," as I understand it), but the code in the OnConnection class does
not execute. Furthermore, if I re-open the COM Add-in dialog, the DLL is not
shown as loaded (though, as mentioned earlier, the registry LoadBehavior
value has, at this point, been set to 9).
I tried a new project, same "extensibility" profile, with load-on-start-up
behavior. It failed to load, similarly to the add-ins described above.
Having run reinstall/repair on Visual Studio, Word, Visual Studio Tools for
Office, just to be sure nothing fundamental had gotten broken, I am mystified.
This reminds me a little of how Macros and wlls fail silently to "load on
demand" with high security settings, and I'm wondering if there is a security
issue. Word security is medium and "trust all installed add-ins" and "trust
access to your visual basic project" are checked.
I'm mystified, and haven't been able to find anything in the MSDN knowledge
base or literature.
Can anyone shed some light?
Thank you.
- Christine