[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework.interop

Com Interop and Type.GetType

Mwob

6/5/2007 1:15:00 PM

Hi,

I am using the Microsoft Caching Block with the database as a backend
store, and all works fine under .NET. I am trying to get the same code
to work when my assembly is called via COM Interop from a VB6 client.
When this happens, the caching block falls over because a call to
Type.GetType has failed to load the required assembly. The Assembly is
fully qualified like this:

Microsoft.Practices.EnterpriseLibrary.Caching.Database.DataBackingStore,
Microsoft.Practices.EnterpriseLibrary.Caching.Database,
Version=2.0.0.0, Culture=neutral, PublicKeyToken=null

The code looks like this:

Type providerType = Type.GetType(typeName, false);

>From what I understand, Type.GetType tries to load the assembly when
GetType is called, so in a normal app it would look in the "debug"
folder if running in debug, and probably the GAC too... But because
this is COM INterop, I don't understand where .NET is looking for the
assembly, and I'm not sure what I can do - perhaps force it to look
somewhere else perhaps?


Can anyone help me?



Matt.
2 Answers

(Mattias Sjögren)

6/5/2007 6:50:00 PM

0


>>From what I understand, Type.GetType tries to load the assembly when
>GetType is called, so in a normal app it would look in the "debug"
>folder if running in debug, and probably the GAC too... But because
>this is COM INterop, I don't understand where .NET is looking for the
>assembly, and I'm not sure what I can do - perhaps force it to look
>somewhere else perhaps?

It will still look in the application directory, but in this case that
means the VB6 application directory (or the VB directory if you're
running from inside the IDE).

Fuslogvw.exe is a great little tool in the .NET SDK for finding the
cause of binding failures.


Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.n... | http://www.dotneti...
Please reply only to the newsgroup.

Mwob

6/6/2007 7:53:00 AM

0

Thanks, I realised this soon after I posted. Unfourtuntely its not so
simple for me - rather than a VB Client exe calling through to
the .NET assembly, it will be a COM component which in turn will be
instantiated from an ASP page.

So, because it goes ASP -> COM -> .NET Assembly -> Caching block, the
caching block looks for the assembly in C:\windows\system32
(presumably because the ASP process (DLLHOST.EXE) is in that folder).

I'm completely stuck - I want to tell the Caching block to load the
assembly from a folder where I know it will be, not in system32. But I
don't know how to do this, or if its possible. I toyed with the idea
of adding the caching block to the GAC, but its heavily bound to the
rest of the enterprise block so even this isn't easy to do.

Any ideas?

On 5 Jun, 19:49, Mattias Sj?gren <mattias.dont.want.s...@mvps.org>
wrote:
> >>From what I understand, Type.GetType tries to load the assembly when
> >GetType is called, so in a normal app it would look in the "debug"
> >folder if running in debug, and probably the GAC too... But because
> >this is COM INterop, I don't understand where .NET is looking for the
> >assembly, and I'm not sure what I can do - perhaps force it to look
> >somewhere else perhaps?
>
> It will still look in the application directory, but in this case that
> means the VB6 application directory (or the VB directory if you're
> running from inside the IDE).
>
> Fuslogvw.exe is a great little tool in the .NET SDK for finding the
> cause of binding failures.
>
> Mattias
>
> --
> Mattias Sj?gren [C# MVP] mattias @ mvps.orghttp://www.msjogren.n...|http://www.dotneti...
> Please reply only to the newsgroup.