CoCreateInstance fails when COM method calling it was called fromassembly

[ranin02]

Hi,

I have a COM method that is called from VBA. This COM method in turn
calls CoCreateInstance on a class that is a .NET class with a COM
wrapper around it. This all works fine. However, when I kick off
that VBA routine from a .NET class within an assembly, I get a class
not registered error. When CoCreateInstance is called on that COM
visible .Net class a second time, then there is a security violation.
To try to make it clearer:


This works:
VBA -- > COM --> CoCreateInstance on COM wrapped .NET class


This does not work (And results in a Class Not Registered Error then
a
security error if CoCreateInstance is called again):
..NET class --> VBA-->COM-->CoCreateInstance on COM wrapped .NET class


The .NET assemblies are not in the GAC -- they are in the same
directory.


Any thoughts?
Thanks,
Sherri

 

[Family Tree Mike]

VBA and VB6 are not equal. You also should not be able to go from your COM
class (VB6 I am assuming) to VBA.

 

[ranin02]

VBA and VB6 are not equal.  You also should not be able to go from your COM
class (VB6 I am assuming) to VBA.

The COM classes are all C++. Not using VB6 anywhere, only VBA (within
Excel). There is no problem with the VBA-->COM communication or COM--

COM wrapped .Net communication. No problem, that is, until the top

level .Net class is introduced.

Thanks,
Sherri

 

[Family Tree Mike]

Then I believe you will find that C++ -> VBA gives the problem also.

 

[ranin02]

Then I believe you will find that C++ -> VBA gives the problem also.

Not sure what you mean. I am able to launch the VBA macro from my
(C#) .Net assembly just fine, and the macro in turn instantiates COM
classes and calls COM methods just fine, and these COM methods call
CoCreateInstance on pure COM classes just fine. It is only when it
attempts to call CoCreateInstance on a class that is a COM
visible .Net class that it has a problem. So it seems to be a .Net
issue -- it is only when there is .Net on the top AND .Net on the
bottom that it has the problem. If there is .Net only on the top, but
not on the bottom, no problem, and vice versa.

Thanks,
Sherri

 

[Family Tree Mike]

I apologize, as I appear to have complete misunderstood the problem earlier.
Is the .net class at the bottom of the chain trying to start a new chain?
That is, what is the logic at the bottom of the chain that is different than
on entry?

And, by the way, there are strange postings going on all over this board on
MSDN. I hope this doesn't further confuse the issue!

 

[ranin02]

I apologize, as I appear to have complete misunderstood the problem earlier.  
Is the .net class at the bottom of the chain trying to start a new chain?  
That is, what is the logic at the bottom of the chain that is different than
on entry?

And, by the way, there are strange postings going on all over this board on
MSDN.  I hope this doesn't further confuse the issue!

At the bottom level, there is a COM class that is trying to call
CoCreateInstance on a COM visible dotnet class. This COM class is
calling CoCreatInstance on a lot of COM classes, which works fine in
both cases -- both when the chain was initiated by an assembly and
when it wasn't. But when it calls CoCreateInstance on the .Net class,
in the case when things were initiated by an assembly at the top
level, the CoCreateInstance fails with Class Not Registered, then the
next time with a security exception -- it never even reaches the .Net
class in this case. Please note that NOTHING is different from VBA on
down in both cases. The only thing that is different when it works
and when it doesn't is that in the case it works, the VBA macro is
called directly from Excel, and in the case when it doesn't, the VBA
macro is launched from an assembly by calling Application.Run. And in
the case when it doesn't work, calls to CoCreateInstance on regular
COM objects work fine, just the call to CoCreateInstance on the COM
Visible .NET class doesn't work.

I have both assemblies (and all intermediate files) located in the
same directory, and for the time being I gave that directory full
trust with the .NET framework config utility.

Thanks,
Sherri