Use .NET DLL from VB6 app -> broken references on rebuild?

  • Thread starter Thread starter Gary McGill
  • Start date Start date
G

Gary McGill

I'm building a set of DLLs in .NET that I plan to call from a VB6
application.

I've almost got that to work, but now I find that whenever I re-build any of
my .NET DLLs, the reference to that DLL in my VB6 project gets broken. So, I
need to re-create the reference after every rebuild. This is incredibly
frustrating and time-consuming.

Is there a way around this?

(PS. I'm using VB6, and VS.NET 2003 with the 1.1. framework.)
 
Are you strong naming the assemblies, setting the versions in the
AssemblyInfo.vb file and have you set the ComClass() attrribute for ClassID,
InterfaceID and EventsID and specified the GUID strings for those clsid
values?

Robert Smith
Kirkland, WA
www.smithvoice.com
 
look here for more info:

http://msdn.microsoft.com/library/d...roughCreatingCOMObjectsWithVisualBasicNET.asp


and in case you're interested:

Best help for you and your coworkers on the project is to go to your local
bookstore today and get Rockford Lhotka and BIlly Hollis' "Professional
Visual Basic Interoperability: COM and VB6 to .Net"

I think it only had a .Net1.0 version ... if it's at your store get it
anyway. The main stuff you need is in it and the differences will be more
easy to figure out after you've read the first several chapters of this
book.

If it's not at your store then rush it from amazon, they've got a deal on it
because of the death of WROX press.

There are other Interop books, some with lots more neat-geeky code that will
make you think that your money will go farther on them ... but it sounds
like you need a crash course and you need it in a syntax that will make it
work for you. This is the book.

Robert Smith
Kirkland, WA
www.smithvoice.com
 
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
 
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/default.asp?url=/library/en-us/dnbda/html/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
 
Boy I hate it when people quickly addendum-post, and here I am doing it
again :)

Meant to say: "VB developers are urged to set version numbers EXplicitly"

Personally I think the VB.Net way is best after you know about the
difference... but, of course, I'm a proud VB developer, and MS knows well my
mindset ;-)

-smith
 
Just checking in... I haven't had a chance to get to a box with VB6 on it
over the weekend. But did manually setting the version numbers do the trick
for you?

-smith
 
Robert,

I've just tried setting an explicit version number, rebuilt my C# DLL, and -
hurrah - the reference from the VB project is not broken. :-)

FYI, I didn't have to strong-name anything, though I probably will.

Gary
 
Like you said easrilier, that was probably the issue, and one that a VB dev
wouldn't notice as much becuase of the diffs in the versioning systems.

Great news & nice working with you ;-)

-Smith
 
Back
Top