Ah, ok.
VB.Net and C# deal with versioning differently. VB.Net doesn't
automatically increment the assembly versions when you use wildcards in the
version attribute of the assemblyinfo file if you're running the same
instance of the IDE (unless you switch from a non-strongnamed build to a
strongnamed build) and VB developers are urged to set version numbers
implicitly, wheras rebuilding with C# will give a new version number on
every build in the same IDE instance.
IMO, strong naming for a production assembly is a correct practice in all
cases and just a good habit to get into. For a detailed set of "Whys" on
versioning and strongnaming you may find the first several paragraphs of the
following link helpful:
http://msdn.microsoft.com/library/de...l/tdlg_ch5.asp
Now, I wanted to check the tlb reference issue for you but I don't have VB6
installed where I am so I'll have to get to it later or maybe someone else
will pop in and help out. It's been a little while since I've been on a
project where I did this every day, but just of the top of my head what I
will be trying first is trying to duplicate the issue by building a .Net
assembly and pointing VB6 at it's tlb where it sits in the .Net build bin
folder, then recompiling (generating a new tlb file) and seeing if the ref
gets hosed ... and if so I'll copy the tlb and dll to a second different
location and point VB6 at it there, then rebuild (without changing the
interface) and just copy the new dll to the second location and see if VB6
is still ok (because it's using the same tlb as before). I'd figure that
the tlb is what's going to make the difference because that's what VB is
linking to. That being said, so long as you're not changing the dll's
interface then using the same tlb should be working... and only if you add
or alter the public interface should you need to set VB6 to a different tlb.
If I can get to this today I will, but maybe someone else can just run these
steps and post the results here.
In any case, please look to the link above, even with C# you might decide
that using strongnames and maintaining your own version numbers is the
real-world best practice, it does get tedious in a solution with multiple
projects/assemblies but it helps keep things straighter in your head over
time.
Robert Smith
Kirkland, WA
www.smithvoice.com
"Gary McGill" <ga*********@electrum.co.uk> wrote in message
news:ON****************@TK2MSFTNGP11.phx.gbl...
Robert,
Thanks very much for your reply, and also for the next one about the book.
Actually it's a C# DLL, but I think I'm doing the equivalent C# stuff for
some of what you mention (GUIDs etc.). Without doing that, I can't see the
DLL/classes/methods from VB at all, so I must be doing something right.
Note
that the problem I have is not that I can't reference call the DLL, it's
just that a recompile of the DLL means that it disappears from the
references list in my VB project.
I haven't done anything with the version number in the
AssemblyInfo.vb^H^Hcs
file, and now that you mention it I can see that that would be a problem
if
the version number is auto-incremented, which I think it might be.
I'm not strong naming the assemblies either - I've yet to find a
description
of why you'd want to do that, but if it's going to help me here then I
will.
I can find plenty of the "how", just not the "why" :-)
Thanks again,
Gary McGill