CoCreateInstanc e 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 CoCreateInstanc e 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 CoCreateInstanc e 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 --CoCreateInstanc e on COM wrapped .NET class
This does not work (And results in a Class Not Registered Error then
a
security error if CoCreateInstanc e is called again):
..NET class --VBA-->COM-->CoCreateInstan ce on COM wrapped .NET class
The .NET assemblies are not in the GAC -- they are in the same
directory.
Any thoughts?
Thanks,
Sherri

[=?Utf-8?B?RmFtaWx5IFRyZWUgTWlrZQ==?=]

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" wrote:

Hi,

I have a COM method that is called from VBA. This COM method in turn
calls CoCreateInstanc e 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 CoCreateInstanc e 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 --CoCreateInstanc e on COM wrapped .NET class
This does not work (And results in a Class Not Registered Error then
a
security error if CoCreateInstanc e is called again):
..NET class --VBA-->COM-->CoCreateInstan ce on COM wrapped .NET class
The .NET assemblies are not in the GAC -- they are in the same
directory.
Any thoughts?
Thanks,
Sherri

[ranin02]

On Jan 15, 12:23*pm, Family Tree Mike
<FamilyTreeM... @discussions.mi crosoft.comwrot e:

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

[=?Utf-8?B?RmFtaWx5IFRyZWUgTWlrZQ==?=]

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

"ranin02" wrote:

On Jan 15, 12:23 pm, Family Tree Mike
<FamilyTreeM... @discussions.mi crosoft.comwrot e:

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

[ranin02]

On Jan 15, 1:29*pm, Family Tree Mike
<FamilyTreeM... @discussions.mi crosoft.comwrot e:

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
CoCreateInstanc e on pure COM classes just fine. It is only when it
attempts to call CoCreateInstanc e 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

[=?Utf-8?B?RmFtaWx5IFRyZWUgTWlrZQ==?=]

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" wrote:

On Jan 15, 1:29 pm, Family Tree Mike
<FamilyTreeM... @discussions.mi crosoft.comwrot e:

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
CoCreateInstanc e on pure COM classes just fine. It is only when it
attempts to call CoCreateInstanc e 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

[ranin02]

On Jan 15, 8:54*pm, Family Tree Mike
<FamilyTreeM... @discussions.mi crosoft.comwrot e:

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
CoCreateInstanc e 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 CoCreateInstanc e on the .Net class,
in the case when things were initiated by an assembly at the top
level, the CoCreateInstanc e 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 CoCreateInstanc e on regular
COM objects work fine, just the call to CoCreateInstanc e 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