Creating a DLL in VS2010 and Referencing it in VB6

Basically I've got this huge project to convert a program in VB6 to a .net framework.

So because the program is so big, my plan is to take some of the VB6 functions in the program now and converted them to a .net DLL and then instead of the VB6 just calling a function it its module, it would call the new function in my new DLL. Over the course of a year I should have all the major functions converted over and in production and then I'll save the GUI interface for last.

However I am having a problem seeing the Members of my Class in VB6

Here is what I did to create a small test to recreate the problem I am having

1. Created a Class Library Project in VS2010
2. In Compile Properties of the DLL I checked to Register for COM interop
3. I selected Sign the Assembly (with no password and gave it a nice name)
4. I created a public function HW in the class which is also public. The function just returns Hello World ect ect. Just a sting.
5. I built my project which created 4 files in the bin/debug directory (DLLTest.dll, DLLTest.pdb, DLLTest.tlb and DLLTest.xml)
6. I then registered the DLL by creating a .bat file (Call C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe "[MY PATH]\DLLTest.dll" /codebase /tlb:"[MY PATH]\DLLTest.tlb" and running it. With a pause on the .bat file I was able to see it registered correctly.
7. Next I opened up a new VB6 Project and selected Standard .exe
8. I added a reference to the DLLTest from the list. (Listed under DLLTest in the list of References)
9. In the form load I set "Dim MyTest As New DLLTest.ClsLab (This is where my HW function is)
10. I then typed MyTest. and nothing came up. However if I type MyTest.HW it works and returns the value I put in to test with

So my problem is how do I get the Members of ClsLab to show up in VB6?

When I reference the DLL in a VS2010 Project, they show up. But they do not show up in VB6.

Its going to be a very challenging year for me if I cannot get the members of these functions show up in VB6.

Thanks,

-Jeff

The Microsoft InteropForms Toolkit 2.1 might be worth looking at. The description suggest forms yet I have done non-form DLL projects with this library.

Frankly, I think you're going about it wrong. From your description, it sounds like you have a working program already. If that is the case, convert the whole thing. By doing it in a two step process, as you propose, you will be doing some things to make the .NET/VB6 version work that you wouldn't have to deal with in the pure .NET version. In both cases you will have to be testing. While it may appear that you can write part of it, test the dlls, then write the GUI, are you really saving yourself any time? After all, what would be the justification for rolling out the hybrid solution when you know that you have a working VB6 version, and will eventually have a working .NET version. Stick with the one while you write an test the other, then switch over. Otherwise you will be switching over twice.

Thanks Kevin, that sound like it is exactly what I am looking for.

Shaggy, if it were up to me it would be one update and I would convert the whole thing. Thanks though.

Quote:

---

Originally Posted by kevininstructor

The Microsoft InteropForms Toolkit 2.1 might be worth looking at. The description suggest forms yet I have done non-form DLL projects with this library.

---

I also played around with this one time. Its works pretty well from what I've seen.

Quote:

---

Originally Posted by Shaggy Hiker

While it may appear that you can write part of it, test the dlls, then write the GUI, are you really saving yourself any time? After all, what would be the justification for rolling out the hybrid solution when you know that you have a working VB6 version, and will eventually have a working .NET version.

---

Depends on the context. If we're talking a business application that needs to be able to respond to changing needs of the business then this ensures that changes can be made and released during the switchover period. Martin Fowler describes this approach as a Strangler Application.

Okay, the toolkit was a little more complicated than what I'm trying to do right now, but at least now I know I can get .net forms in VB6 if needed down the road.

However The Functions in my DLL are just returning values

So I did a little more googling and came across this article.
http://support.microsoft.com/kb/817248

Turns out the solution to my problem was simple. I was using a CLASS instead of a Com Class

So basically... Just adding a new Com Class to my project and then taking my functions from my Class and cutting them and pasting them into the ComClass fixed everything. Just did a build, opened up the VB6 app and sure enough the members are there under Object Explorer.

Literally took seconds and was just the quick fix I was looking for.

And yes Evil_Giraffe that I think that is the approach we are taking with this project. While one big update would be nice, I think a slow approach will be better to allow for updates to still go in while we are in the process of converting. This way we can not only slowly introduce our .net code over the VB6 but still offer the ability to allow updates/enhancements to go in without having to support a separate set of code while we are in the process of converting to .net

Thanks for the Article. I'm sure it will make my management more confident that this is the right approach. Although I would prefer to just deal with one release, I see their point of view on breaking this out into several releases this year.

Thanks Again.

So as I begin to convert I hit another bug...

Public Functions returning a long value do not work. I must convert all my Longs to Integers to work on VB6

Which is fine because if remember correctly in .net an integer is basically a long, so I shouldn't have any issues with a stackover flow when my number gets to large. Right?

correct... an Integer in .NET is currently a 32-bit integer, which is a Long in VB6.
A Long in .NET results in a 64-bit integer... which in VB6 is a ... I don't remember if there is anything that is the same...

-tg

The only 64-bit wide numeric data type in VB6 is Currency. However, I wouldn't wager that COM would translate a Long from .Net to that as the Currency data type stores a fixed point number and a .Net Long is an integer.