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=F6gren <mattias.dont.want.s...@mvps.org>
[quoted text, click to view] 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=F6gren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dot= net/|
http://www.dotnetinterop.com > Please reply only to the newsgroup.