Use string name for your assembly and put in GC.

the C# project, and also using regasm /tlb on the deployed machine, the VB6
app will only 'find' the C# DLL if it located in the same directory.  The C#
DLL has been registered and resides in the winnt\system32 directory, which
is in the path.

the C# project, and also using regasm /tlb on the deployed machine, the VB6
app will only 'find' the C# DLL if it located in the same directory.  The C#
DLL has been registered and resides in the winnt\system32 directory, which
is in the path.

===============================================
See the following:

MSDN:  Working with Assemblies and the Global Assembly Cache
"In addition, you do not have to install assemblies into the global assembly
cache to make them accessible to COM interop or unmanaged code."

The following also apply:

MSDN: Exposing .NET Framework Components to COM
MSDN: Registering Assemblies with COM

If you want the down and dirty on the process that takes place when the CLR
probes for assemblies, try the Fusion Log View tool (fuslogvw.exe) - it will
show the assembly probing that takes place when an app tries to "find" a
.Net assembly.

If you are using an Installer class for your assembly, you can set the path
to your assembly by the following:

// Override the 'Install' method of the Installer class.
public override void Install( IDictionary mySavedState )
{
   base.Install( mySavedState );
   ...
   RegistrationServices rs = new RegistrationServices();
   // get refererence to your assembly
   Assembly asm;
   ...  (use Assembly.GetAssembly("yourtypename") etc. here to get a
reference to your assembly)
   // set the CodeBase for your assembly
    rs.RegisterAssembly( asm, AssemblyRegistrationFlags.SetCodeBase);  //
allows CLR to find the assembly when invoked from COM
   ...
}

the C# project, and also using regasm /tlb on the deployed machine, the VB6
app will only 'find' the C# DLL if it located in the same directory.  The C#
DLL has been registered and resides in the winnt\system32 directory, which
is in the path.

BTW Putting your assemblies into a public path such as Windows or
Windows/System32 is contrary to recommended .Net practices ("Back to DLL
hell we go...") Another failing is that the runtime stub doesn't use the
path when locating assemblies.

I don;'t agree with the posting regarding "Stick it in the GAC", unless it
is a shared assembly - it's a "sledgehammer" solution. If you are using
other assemblies (e.g. - shdocvw) then you end up having to give all your
dependent assemblies strong names and distribute them as well, not just your
"topmost" assembly invoked by COM.

Finding information on invoking .Net assemblies from an unmanaged COM app
takes some digging in MSDN. Another relevant topic I had bookmarked::

"How the Runtime Locates Assemblies"

Pay special attention to the section on "Checks whether the assembly name
has been bound to before".  The runtime caches assembly regferences,
resulting in some interesting "it worked...then it didn't work" situations.

The info regarding the <codebase> config file entry doesn't apply in your
case, since you are running in the context of an unmanaged app.  However,
setting the registry entry for HKCR/<yourguid>/InprocServer32/Codebase
(which is what happens using RegistryServices.RegisterAssembly() using the
SetCodeBase flag.