HOW TO register VS.net addin for office manually?

K

Kevin

hi.all

since I post a similar thread a whle ago, but no one replyed to that one,
now I am asking a more specific question, sort of.

I wrote a word COM addin for word 2003 in vs.net using the share-addin
template, it works in the development machine and everything.

but now I am having trouble getting it to work in the client machine(in the
client machine, the full office 2003 pro is installed,
so the office 2003 PIAs should be there). I installed the addin using the
installer that created alone with the addin project, but the
addin don't seemed to load. so I wonder how can I manually install the
addin? eg. beside copying the dll into GAC and adding the
registry keys. how do I register the COM interop for the managed dll?


thx


Kevin
 
C

Chango V.

If your addin is .NET-based, the assembly needs to be registered for COM
interop with regasm. You may also need the (somewhat controversial) option
/codebase.

//
 
K

Kevin

Chano

would you please provide more detail please?

have you done that in your project?


thanks


Kevin
 
C

Chango V.

reagasm.exe is the .NET Framework utility that registers assemblies for COM
interop. Normally it takes just the assembly filename. The /codebase option
is needed when the assembly DLL does not reside within the folder subtree
where the main executable is. This is the case with Office add-ins. In your
case, the CLR considers the folder where WinWord.exe is to be the 'base
application path'. The make the .NET assembly load, it either has to be
located in that folder or a subfolder, or you need the /codebase option. The
documentation says it should be used only for Debug builds, but we have
found no other way to load our Word add-in, EXCEPT adding it to the GAC, but
we have reasons not to put it there (and, unless an assembly is shared, it
is not recommended to be placed in the GAC).

If your add-in registry keys are OK (under
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Word\AddIns) and the addin
still does load, here's a debugging hint: Programmatically toggle the
COMAddin.Connect property. If loading fails, see what's in the exception
error message. (Normally, it just fails silently and you have no clue.)

Good luck.

// Chango V.
 
K

Kevin

Chango

reagasm.exe is the .NET Framework utility that registers assemblies for COM
interop. Normally it takes just the assembly filename. The /codebase option
is needed when the assembly DLL does not reside within the folder subtree
where the main executable is. This is the case with Office add-ins. In your
case, the CLR considers the folder where WinWord.exe is to be the 'base
application path'. The make the .NET assembly load, it either has to be
located in that folder or a subfolder, or you need the /codebase option. The
documentation says it should be used only for Debug builds,
Click to expand...

is that why the addin works in my machine during the debug run?
but it works for the release version too, it also use the installer to
install
the addin on the development machine.



but we have
found no other way to load our Word add-in, EXCEPT adding it to the GAC, but
we have reasons not to put it there (and, unless an assembly is shared, it
is not recommended to be placed in the GAC).
Click to expand...

on the client machine, no error messages were given, the addin just wouldn't
load.

ok. I tryed copying the assemblies (including all dependency dlls) into the
folder where
winword.exe reside, the addin won't loan, I even try registering the addin
dll in the GAC,
still won't loan. what am I missing? the MVPs said the installer should
work, plus I didn't
add any dll mannually to the installer. I also read something about
including the office PIA
in the installer, but there are only three dlls in the installer, the
closest dll to PIA would be
the office.dll, should I include office.dll from the installer?

thx

Kevin
 
C

Chango V.

Kevin,

Do the simple add-in loading test I described before: setting the
COMAddin.Connect property programmatically (from within a VBA code module).
Loading will fail, but you'll potentially get a useful error message in the
Err object.

Here's also a simple test whether your assembly is properly registered for
COM interop. In a test VBA code module, try this:

sub Test()
set obj = CreateObject("MyAddInName.Connect") ' (put real ProgId here)
end sub

This will test your add-in just as a COM server. If that works, then the
only other reasons I can think of Word wouldn't load the add-in are:
-- Bad or missing add-in registration keys. (Check under
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Word\AddIns.)
-- Check Word 2003's Disabled Items list: Help menu, About, Disabled Items.

Good luck.

//

Direct email: [email protected]
 
K

Kevin

Chango
Thanks for the reply.

I tried the VBA code, it didn't give me any error message on the client
machine.
(I also have a little message box after creating the object)
I even change the ProgID to a random name to test, it gave me a runtime
error,
so I know the VBA code is also working, which mean the COM addin is properly
registered. but why word won't load it? I also chech the registry key, the
COM addin
entry is under the word addins like this:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Word\Addins\wsAcronymsWord.Con
nect]
"Description"="NRCAN Acronyms lookup Addin."
"LoadBehavior"=dword:00000003
"FriendlyName"="WSAcronyms"

now what can I do?

Kevin
 
M

Matrim Cauthon

Kevin said:
by the way, can I email you the project, so that you can see what's going
on?
Click to expand...


Dont let this thread die please, I encountered a similar problem =/
 
Top