Outlook add-in : COM object not created. How to find the error? RS

[Cedric]

Hello all,

I'm working since quite some time on a COM outlook add-in made with vb 2008
express.
after a change in the code, it refuses to run ("error loading..." in the
apropriate Outlook dialog box). the change was adding a vb file (module) and
call a function in it. I went backward but the problem keeps happening.
(??!!) It occured some times ago and disapeared I don't know how (magic!)
I used a bit of VBScript to test the object behavior:

Option Explicit
Dim objAddin
const PROGID = "Quinoa.Connect"

On Error resume next

Set objAddin = Nothing

Set objAddin = CreateObject(PROGID)

If Not objAddin Is Nothing Then
WScript.Echo "The object has been created!"
Set objAddin = Nothing
else
WScript.Echo "The object has NOT been created!"
End if



and the execution gives "The object has NOT been created!"
Given that I use VB express, I can't use the debug mode, as the application
to run is Outlook.
i have added a msgbox at the very first function call (OnConnection), but it
doesn't show up. Which means that the bug is somewhere before the first line
of code (??!!). i guess a problem with using a DLL or so somewhere I can't
actually do anything... The real problem being I don't know what really goes
wrong.


I also tried with ADDInSpy but everything seems right in the report.
Can anybody please help me finding the answer?

TIA all

Cedric

 

[Ken Slovak - [MVP - Outlook]]

You can't just use CreateObject() on an addin DLL. An addin DLL loads when
the host application loads (or on demand), and has to be registered in a
specific place in the registry with specific registry keys for the addin to
be recognized and loaded by Outlook.

Normally when debugging you start your addin in the debugger and set the
Debug properties to start up your target host application. I have no idea
how an express version might be different for that though.

For registration you need the following in either HKCU or HKLM at
\Software\Microsoft\Office\Outlook\Addins:

LoadBehavior DWORD 3
Description REG_SZ
FriendlyName REG_SZ
CommandLineSafe DWORD 0

Usually that's set up in your installer and then you compile and install so
you're ready to either run or debug.

 

[Cedric]

Hi Ken,

thanks for your reply!

I had previous problems with my add-in. The script returned the expected
"The object has been created!".

In the express edition, it is not possible to debug an add-in simply because
you can't set an external application as the application to start for debug.
This is explicitly mentioned in VB express features.

Regarding the reg keys, I have inserted them. I also registered my add-in
with regasm and option /codebase.
My add-in have been working for quite some time. It's these latest changes
that made it crash.

I also have a fallback plan that is re-create my add-in from scratch and
copy/pase or move my vb source files. But this is a bit time consuming, it's
the 3rd time I'd have to do so since I started making this add-in and I get
bored. So I'd like to understand what really goes wrong from time to time,
and solve it once for all.

Thanks again for your help so far!

Cedric

 

[SvenC]

Hi Cedric,

after a change in the code, it refuses to run ("error loading..." in the
apropriate Outlook dialog box). the change was adding a vb file (module)
and
call a function in it. I went backward but the problem keeps happening.

Is that function in another dll? Is that dll in the same directory as your
addin so that it can be found and loaded?

Use "Process Monitor" to watch Outlook.exe when it accesses the file
system and registry at the point your add in fails to load. You might
see some dlls which cannot be found. Copy those into the directory
of your addin.
Might as well be some code access security checks which prohibit
access to legacy dlls but I do not know much about how that works.

 

[Ken Slovak - [MVP - Outlook]]

Well, I still wouldn't try to create the addin dll instance using
CreateObject(). The addin loader in Outlook is supposed to do that when
Outlook starts if the registry keys for the addin are there and correct.

What I'd be using in the script is to call
CreateObject("Outlook.Application") to start Outlook and let the addin
loader handle starting the addin dll.

One thing to look for with managed code is the Fusion logs. Fusion is what
loads managed addin code so any load errors will be in those logs. See
http://blogs.msdn.com/vsod/archive/2008/04/22/Troubleshooting-com-add-in-load-failures.aspx
for more information on troubleshooting managed code load errors.

 

[Cedric]

Hi SvenC !

As I said previously, i simply added a vb module. the code is included in my
own DLL, so I don't think the issue is there.

Ken, if you come to read this post, i'll need to spend some more time on
your ideas. Sounds good.

Thank you all for your help!
I keep you posted.

Cedric.

 

[Cedric]

Hi Ken,

based on your feedbacks, I used fusion logs to understand what's happening,
and I'm a bit confused : it seems my add-in is searched in the GAC and in the
default outlook folder. Not in the location where I register the file with
RegAsm. Furthermore, I thought that GAC thing had to be set only with vsto
add-ins. I admit I rad some things avout it some times ago and I don't
remember well, since it was working with the regasm + reg entries like those
you told earlier.

by the way:
* In VB express, the installer is not built with visual studio : the only
deployment tool available is ClickOnce, and this only for exe files, not DLL.
So I had to build my own installer. And it includes the reg entries + regasm
/codebase.
* If you look in the page you last told me, in the section "Steps common to
both managed and unmanaged Add-Ins", at the step 3, they speak about what I
did with the vbscript. You might find it useful. In my case, it only confirms
that there's a problem with the dependencies. The fusion log tells a lot
more, though.

I'll keep searching about this "file not found" issue, but if you have any
idea, please share.

Thanks for your help so far, that's useful!

Cedric.

 

[SvenC]

Hi Cedric,

based on your feedbacks, I used fusion logs to understand what's
happening,
and I'm a bit confused : it seems my add-in is searched in the GAC and in
the
default outlook folder. Not in the location where I register the file with
RegAsm. Furthermore, I thought that GAC thing had to be set only with vsto
add-ins. I admit I rad some things avout it some times ago and I don't
remember well, since it was working with the regasm + reg entries like
those
you told earlier.

Please show us your COM addin registry settings.

 

[Ken Slovak - [MVP - Outlook]]

The only ideas I have are neutral to how you actually deploy the addin, they
apply in all cases.

An Outlook addin must be registered in either HKCU or HKLM, under
\Software\Microsoft\Office\Outlook\Addins. Under that key you have your
addin's ProgID. Under that key you have values for LoadBehavior, Description
and FriendlyName.

The actual addin connect class must be registered in HKCR, along with any
other classes in the addin. In cases where a shim is used, either
VSTO-supplied or some other shim, the shim would be registered in HKCR and
it would in turn load the addin class after establishing an AppDomain for
the addin to isolate it from any other addin code.

Any dependent assemblies that you use or call must be available on the
target machine, whether installed by you or by some other means. If those
dependent assemblies need to be registered that also must be done.

When Fusion loads something it first looks in the GAC, then in the folder
where the code is being executed from and in other specific known locations.
If it doesn't find what it's looking for it then gives up and posts a
failure message.

 

[Cedric]

Hello all,

Sorry for not giving feedbacks before today : I had problems accessing the
forum.

good news, the problem is now solved!
Thank you two for your help, especially Ken.

The issue was due to an inaccurate version number: it could happen that
when building a new version, the right-most number was set to a value lower
than the previous one. As I couldn't debug my add-in straight from visual
studio due to the limitations of the express edition, i had built a command
line script which was in charge of overwriting the dll in its install folder
and register the file.
Outlook was looking for the latest version, which had been overwritten. A
few registry cleanup and unregistering the file before overwriting it seemed
to solve the issue.

Thanks again for your precious help, wishing I can give this back to you
some day!

Cedric.