> -Original Message-
> From: Brent E. Rector [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 31, 2002 12:57 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [DOTNET] COM Interop calling a C# DLL from VB6
>
>
> The best technique is setting the GUID/IID/CLSID's using
-
> From: Brent E. Rector [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 31, 2002 10:57 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [DOTNET] COM Interop calling a C# DLL from VB6
>
> The best technique is setting the GUID/IID/CLSID's using the
> GuidAttribute. However,
]]
> Sent: Friday, May 31, 2002 10:16 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [DOTNET] COM Interop calling a C# DLL from VB6
>
>
> Also, it seems better to have all your classes implement an interface,
> and then use those interfaces for the TypeLibs.
>
> Question:
Adam Nathan [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 31, 2002 11:37 AM
To: [EMAIL PROTECTED]
Subject: Re: [DOTNET] COM Interop calling a C# DLL from VB6
Right, recompiling with no changes does not change the auto-generated
GUIDs. Note that auto-generated LIBIDs and CLSIDs are based off of th
ute).
This will cause your GUIDs to change on re-compile unless you change it
to be a fixed version.
Adam
-Original Message-
From: Brent E. Rector [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 31, 2002 10:57 AM
To: [EMAIL PROTECTED]
Subject: Re: [DOTNET] COM Interop calling a C# DLL fro
EMAIL PROTECTED]
Subject: Re: [DOTNET] COM Interop calling a C# DLL from VB6
Also, it seems better to have all your classes implement an interface,
and then use those interfaces for the TypeLibs.
Question: Is the compiler at this point handling all the binary
compatibility issues?
If I have a DLL a
Take a look at the attribute flag. It should allow you to
specify the uuid for each interface, so that they do not change between
compiles. That's as close to binary compatibility as I've found, although
you (the programmer) are required to uphold the contract of no interface
changes - it's not d
aid).
>
>
> >From: Patrick Burrows <[EMAIL PROTECTED]>
> >Reply-To: dotnet discussion <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: Re: [DOTNET] COM Interop calling a C# DLL from VB6
> >Date: Fri, 31 May 2002 11:30:55 -0400
> >
> >
can perfectly use Private assemblies as long as they are in the right place
(also as Brent said).
>From: Patrick Burrows <[EMAIL PROTECTED]>
>Reply-To: dotnet discussion <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: [DOTNET] COM Interop calling a C# DLL from VB6
uivalent of the
> > registry) and
> > give it a strong name (the equivalent of a GUID).
> >
> >
> > Richard
> >
> > > -Original Message-
> > > From: dotnet discussion
> > [mailto:[EMAIL PROTECTED]]On Behalf
> > > Of
spx
>
>
>
> -Original Message-
> From: Richard Birkby [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 31, 2002 7:41 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [DOTNET] COM Interop calling a C# DLL from VB6
>
>
> COM classes are globally registered in the Regis
AM
To: [EMAIL PROTECTED]
Subject: Re: [DOTNET] COM Interop calling a C# DLL from VB6
COM classes are globally registered in the Registry. To do this, they
need a unique ID - a GUID.
By default, .Net classes are not globally registered. To do this, you
must place the assembly in the GAC (the equiv
name (the equivalent of a GUID).
Richard
> -Original Message-
> From: dotnet discussion [mailto:[EMAIL PROTECTED]]On Behalf
> Of Patrick Burrows
> Sent: 31 May 2002 14:22
> To: [EMAIL PROTECTED]
> Subject: [DOTNET] COM Interop calling a C# DLL from VB6
>
>
> Ok.
).
Richard
> -Original Message-
> From: dotnet discussion [mailto:[EMAIL PROTECTED]]On Behalf Of
> Patrick Burrows
> Sent: 31 May 2002 14:22
> To: [EMAIL PROTECTED]
> Subject: [DOTNET] COM Interop calling a C# DLL from VB6
>
>
> Ok... I guess I'm not understandin
Ok... I guess I'm not understanding what a strong name is (in .NET
terms). Why do I need a snk file? All I want to do is call my C# DLL
from VB6.
I use sn.exe to create an SNK file. And I set AssemblyKeyFile and
AssemblyKeyName properties. But it is still saying my Assembly doesn't
have a strong
15 matches
Mail list logo