Re: App.path - equivalent - in an interop DLL
From: Ellen (bottas_at_kkl.com)
Date: 05/18/04
- Next message: Rob: "Re: Memory leak in .NET service on Windows 2000"
- Previous message: Chris Gallucci: "Re: App.path - equivalent - in an interop DLL"
- In reply to: Ellen: "Re: App.path - equivalent - in an interop DLL"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 18 May 2004 11:59:53 -0400
[I know it's lame to answer myself, but I figured someone else might
come looking for this later.]
Ellen wrote:
> I want this to work with COM interop too, so
> I can hook it into some existing VB6 apps. AFAIK, part of registering a
> .NET DLL for use with interop is registering it into the GAC with
> gacutil. Is that strictly necessary?
To answer my own question: No. The alternative:
1) Make sure you have a public interface available, and make sure Class1
implements it.
2) set project properties to "Register for COM Interop" = True
3) in AssemblyInfo.cs, add attributes:
[assembly: ComVisible(true)]
[assembly: ClassInterface(ClassInterfaceType.None)]
4) generate guids for the interface and the class to keep binary
compatibility (so you can use early binding in your VB6 project).
Beware though, .NET insists on copying the damn thing into C:\Documents
and Settings\{profile}\etc etc... and working from that copy *WHILE
YOU'RE IN THE IDE*. Which is retarded, IMHO, since the final
COM-registered copy does in fact end up where you thought you were
working. But hey.
So comment out all that stuff while you're working on it and uncheck the
Register for Interop property. Set it back when you're ready to
"publish" it to COM.
>
> Because it seems that when I do *that*, the path that gets returned from
> VB6 code like:
>
> dim o as object
> set o = CreateObject("MyTest.Class1")
> msgbox o.FindMe
>
>
> is c:\windows\assembly\gac\test\1.0.1599.14565__d78c501879e5dc01\mytest.dll
>
>
> So it seems gacutil really throws things off. I guess it's because
> that's actually the executing assembly. Is there any way to trace that
> back to its original path (i.e. c:\test\mytest.dll)?
>
See above. If you don't use the GAC, then
Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location) will
return the path to the DLL.
- Next message: Rob: "Re: Memory leak in .NET service on Windows 2000"
- Previous message: Chris Gallucci: "Re: App.path - equivalent - in an interop DLL"
- In reply to: Ellen: "Re: App.path - equivalent - in an interop DLL"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
