Page 1 of 2 12 LastLast
Results 1 to 40 of 50

Thread: VB6 and .NET interoperability

  1. #1

    Thread Starter
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    9,852

    VB6 and .NET interoperability

    Ok, I'll start a thread that's actually useful for me.

    I mentioned in another thread that my primary client is embarking on a huge upgrade, with the biggest part of it being a translation to .NET. I know I've seen this, but I've never actually done it: VB6 can be inter-operable with .NET, right?

    I've got the community edition of Visual Studio installed, and I'd like to conceptually start playing with this. More specifically, I'd like to start writing .NET DLLs that are called from a VB6 program. Our current proposal is to take one VB6 DLL at a time and translate it to .NET, and then alpha and beta testing these, taking what they're calling an "agile" approach to the translation.

    There are already a dozen or so DLLs as part of this application, and my initial job is going to be cutting out more big chunks, making them DLLs as well (in preparation for this "agile" translation).

    During the translation, it's assumed that we'll stay completely 32-bit. However, they desire to ultimately get to a pure 64-bit system. I'm hoping/assuming that it'll be a simple recompile once it's all translated and tested.

    Anyone done this VB6 and .NET interoperability with .NET DLLs? Anyone have an example?
    Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.

  2. #2
    Smooth Moperator techgnome's Avatar
    Join Date
    May 2002
    Posts
    34,531

    Re: VB6 and .NET interoperability

    It's been a lonnnnng time.... but yeah.... it's been done...
    a system I worked on a couple of life times ago was based on a plugin type system written in VB6... each screen was built as an OCX control that was loaded at run time.
    When they decided to move to .NET... the first thing to be done was re-write the console portion of it in .NET, so that it could support the old original VB6 OCX contrrols while also supporting newer .NET based components. So it's possible. I don't remember how it was done, like I said it was a couple of lifetimes ago and I left hte company a few months later after the start of the initiative, so I don't remember much.


    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  3. #3
    Sinecure devotee
    Join Date
    Aug 2013
    Location
    Southern Tier NY
    Posts
    6,582

    Re: VB6 and .NET interoperability

    Normally you shouldn't duplicate posts, but I'm wondering if this question should be asked on the .Net side as well.
    Perhaps if someone steeped in .Net that was formally steeped in VB6, still visits the VB6 forum, so it won't make a difference, they will see your post here anyway, but I wonder.

    I'm thinking that having .Net use a vb6 DLL is easier than the reverse, but that is just an impression. I haven't dealt with integrating either direction, as far as I know <shrug>.
    "Anyone can do any amount of work, provided it isn't the work he is supposed to be doing at that moment" Robert Benchley, 1930

  4. #4

    Thread Starter
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    9,852

    Re: VB6 and .NET interoperability

    Quote Originally Posted by passel View Post
    Perhaps if someone steeped in .Net that was formally steeped in VB6, still visits the VB6 forum, so it won't make a difference, they will see your post here anyway, but I wonder.
    Well, I'll stick to the VB6 side for now, as I don't really know the folks over there. This isn't something that's going to be fast-tracked, so I've got time.

    Quote Originally Posted by passel View Post
    I'm thinking that having .Net use a vb6 DLL is easier than the reverse, but that is just an impression.
    Regarding this, the largest "chunk" of this application is always going to be the main project, and I'd like to translate that last, so we can all get steeped in how to do this stuff from working on the smaller things. So, I'm truly hoping to do it the way I outlined, VB6 program calling .NET DLLs.

    EDIT1: Worst case, I suppose I could have a .NET startup that then calls the large VB6 chunk ... and then, that large VB6 chunk sends messages back to the .NET startup core to call other .NET components. That's a complexity I'd like to avoid though, hoping to stick more to a line-by-line translation as a first-pass at this thing.

    EDIT2: Just a trivial example of a VB6 program calling (not shelling) to something compiled with .NET would be huge for me. Also, I'd really really like to pass COM objects into these .NET DLLs.
    Last edited by Elroy; Dec 3rd, 2019 at 06:27 PM.
    Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.

  5. #5
    Lively Member Grant Swinger's Avatar
    Join Date
    Jul 2015
    Posts
    71

    Re: VB6 and .NET interoperability

    I did a lot of this back in the day for insurance companies. They were big users of Classic VB and much of the work involved rewriting big VB applications in VB.NET piecemeal. It sounds like what you're doing.

    For an example try this, it might get you started.


    Search Amazon for ".NET and COM". I can recommend the books by Adam Nathan and Andrew Troelsen on the subject. You can still get copies of their books and anybody who deals with both VB6 and .NET should have them.

  6. #6
    Smooth Moperator techgnome's Avatar
    Join Date
    May 2002
    Posts
    34,531

    Re: VB6 and .NET interoperability

    Quote Originally Posted by Elroy View Post
    Well, I'll stick to the VB6 side for now, as I don't really know the folks over there. This isn't something that's going to be fast-tracked, so I've got time.



    Regarding this, the largest "chunk" of this application is always going to be the main project, and I'd like to translate that last, so we can all get steeped in how to do this stuff from working on the smaller things. So, I'm truly hoping to do it the way I outlined, VB6 program calling .NET DLLs.

    EDIT1: Worst case, I suppose I could have a .NET startup that then calls the large VB6 chunk ... and then, that large VB6 chunk sends messages back to the .NET startup core to call other .NET components. That's a complexity I'd like to avoid though, hoping to stick more to a line-by-line translation as a first-pass at this thing.

    EDIT2: Just a trivial example of a VB6 program calling (not shelling) to something compiled with .NET would be huge for me. Also, I'd really really like to pass COM objects into these .NET DLLs.
    There's a setting in the project properties of .NET ptojects "Make COM Visible" .... that will assign it a CLASSID, a GUID, and register it in the registry (or allow it to be if it isn't done automatically) which will then allow you to see it from the VB6 side of things.
    For the most part, it shouldn't be a big deal, just keep in mind the difference between integers though (16 bit in VB6 vs 32 in .NET) so if you're shuttling integers back and forth, onthe VB6 side they need to be longs and integers on the .NET side. Other than that, I think it should be mostly seemless.

    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  7. #7

    Thread Starter
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    9,852

    Re: VB6 and .NET interoperability

    Quote Originally Posted by Grant Swinger View Post
    For an example try this, it might get you started.
    Grant, thank you. This looks VERY promising. I'm tired right now, but I'll take a closer look at this over the next few days.

    -------

    And Techgnome, thanks for the tip. I didn't think it was going to be a huge deal. It's just not something I've done before. And yeah, I've got some C background, so I'm familiar with the Short=Integer, and Int=Long type things. Once we get rolling, I'm hoping some careful global search-and-replaces will solve much of this. And it's things like this that are causing me to tell people that this isn't trivial, and that we need to plan for rigorous alpha-testing and beta-testing periods.

    The first objective will be to do a simple-and-straightforward translation, trying not to "break" anything. I've told them that this will be HUGE, and the users won't (hopefully) see any changes. I'm more used to rolling out updates, and have people say, "Oh WOW, cool, I love the new features." But this won't have any of that.
    Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.

  8. #8
    Fanatic Member
    Join Date
    Aug 2016
    Posts
    597

    Re: VB6 and .NET interoperability

    DSOFramer.ocx is developed by MS. But I guess not being written by VB6. But I still can use it in C#. So, I think we can use VB6's ActiveX in .NET as well.

  9. #9
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Location
    Sofia, Bulgaria
    Posts
    5,120

    Re: VB6 and .NET interoperability

    Quote Originally Posted by Elroy View Post
    Grant, thank you. This looks VERY promising. I'm tired right now, but I'll take a closer look at this over the next few days.

    -------

    And Techgnome, thanks for the tip. I didn't think it was going to be a huge deal. It's just not something I've done before. And yeah, I've got some C background, so I'm familiar with the Short=Integer, and Int=Long type things. Once we get rolling, I'm hoping some careful global search-and-replaces will solve much of this. And it's things like this that are causing me to tell people that this isn't trivial, and that we need to plan for rigorous alpha-testing and beta-testing periods.

    The first objective will be to do a simple-and-straightforward translation, trying not to "break" anything. I've told them that this will be HUGE, and the users won't (hopefully) see any changes. I'm more used to rolling out updates, and have people say, "Oh WOW, cool, I love the new features." But this won't have any of that.
    This kind of "direct translation" would be moderately complex. The real challenge will be to come up with solid unit-testing infrastructure which might need to re-architecture parts of the application in a more testable/mockable implementation. TDD is hard and needs special attention, reading books and articles on design-patterns that are testable, admitting "shortcuts" in VB6 code, re-imagining building blocks and fundamentals of the large application.

    Instrumenting tests is like a game-changer and may serve as a motivation for such .Net migration, not any added functionality to the end product. Nowadays only the very bravest developers produce code with no test coverage at all and in this sense most VB6ers are like Mel Gibsons of the world :-))



    cheers,
    </wqw>

  10. #10
    PowerPoster ChrisE's Avatar
    Join Date
    Jun 2017
    Location
    Frankfurt
    Posts
    3,041

    Re: VB6 and .NET interoperability

    Hi Elroy,

    you might not want to here this but IMO if your Client want's this change
    start over completely.

    take just one section of the VB6 Program at a time and rewrite that part.

    I know I've been there


    regards
    Chris
    to hunt a species to extinction is not logical !
    since 2010 the number of Tigers are rising again in 2016 - 3900 were counted. with Baby Callas it's 3901, my wife and I had 2-3 months the privilege of raising a Baby Tiger.

  11. #11
    Smooth Moperator techgnome's Avatar
    Join Date
    May 2002
    Posts
    34,531

    Re: VB6 and .NET interoperability

    Quote Originally Posted by ChrisE View Post
    Hi Elroy,

    you might not want to here this but IMO if your Client want's this change
    start over completely.

    take just one section of the VB6 Program at a time and rewrite that part.

    I know I've been there


    regards
    Chris
    That is what he's doing... so soon he'll have one part in VB6 and one part in .NET.... so now how to get the two parts to interact? That was his concern. It should be straight forward, but proceed with caution.

    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  12. #12
    Sinecure devotee
    Join Date
    Aug 2013
    Location
    Southern Tier NY
    Posts
    6,582

    Re: VB6 and .NET interoperability

    Quote Originally Posted by techgnome View Post
    That is what he's doing... so soon he'll have one part in VB6 and one part in .NET.... so now how to get the two parts to interact? That was his concern. It should be straight forward, but proceed with caution.

    -tg
    What he is doing isn't what ChrisE was suggesting.

    ChrisE is suggesting a complete rewrite of the VB6 to .Net, without having interaction between the two.
    Its just that you would do that rewrite in small parts. Each rewritten part ported to .Net working as a standalone testable piece, and integrated into a growing .Net solution, not an integrated piece that had to work in situ with VB6.

    You would only deliver the fully ported version after the full port is done, without need for interaction between Vb6 and .Net.

    Its just his opinion of the approach that should be taken, that has worked for him in the past.
    Last edited by passel; Dec 4th, 2019 at 07:24 AM.
    "Anyone can do any amount of work, provided it isn't the work he is supposed to be doing at that moment" Robert Benchley, 1930

  13. #13
    Smooth Moperator techgnome's Avatar
    Join Date
    May 2002
    Posts
    34,531

    Re: VB6 and .NET interoperability

    Quote Originally Posted by passel View Post
    What he is doing isn't what ChrisE was suggesting.

    ChrisE is suggesting a complete rewrite of the VB6 to .Net, without having interaction between the two.
    Its just that you would do that rewrite in small parts. Each rewritten part ported to .Net working as a standalone testable piece, and integrated into a growing .Net solution, not an integrated piece that had to work in situ with VB6.

    You would only deliver the fully ported version after the full port is done, without need for interaction between Vb6 and .Net.

    Its just his opinion of the approach that should be taken, that has worked for him in the past.
    So, take a chunk, rewrite it... and then what? Let it sit there, getting stale? Meanwhile, what if it takes three years to get the conversion done? In the meantime does all development stop on the VB6 end too? So there's nothing happening from the user's perspective for... years? Chris is right, that's not a message anyone wants to hear.


    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  14. #14
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,988

    Re: VB6 and .NET interoperability

    Quote Originally Posted by techgnome View Post
    So, take a chunk, rewrite it... and then what? Let it sit there, getting stale? Meanwhile, what if it takes three years to get the conversion done? In the meantime does all development stop on the VB6 end too? So there's nothing happening from the user's perspective for... years? Chris is right, that's not a message anyone wants to hear.


    -tg
    That's true. There's usually a considerable amount of politics surrounding a decision like this. Perhaps Elroy is in a position to influence that, and perhaps not. Basically, if this transition has created a political firestorm in the country...well, you know how it goes: Any port in a storm.
    My usual boring signature: Nothing

  15. #15
    Fanatic Member
    Join Date
    Feb 2017
    Posts
    858

    Re: VB6 and .NET interoperability

    Just to throw out something here.
    Every thought of moving it to C++.
    I haven't checked lately but as I recall there are convertors already available from VB6 to C++.

  16. #16
    Wall Poster TysonLPrice's Avatar
    Join Date
    Sep 2002
    Location
    Columbus, Ohio
    Posts
    3,834

    Re: VB6 and .NET interoperability

    Quote Originally Posted by Elroy View Post
    Ok, I'll start a thread that's actually useful for me.

    I mentioned in another thread that my primary client is embarking on a huge upgrade, with the biggest part of it being a translation to .NET. I know I've seen this, but I've never actually done it: VB6 can be inter-operable with .NET, right?

    I've got the community edition of Visual Studio installed, and I'd like to conceptually start playing with this. More specifically, I'd like to start writing .NET DLLs that are called from a VB6 program. Our current proposal is to take one VB6 DLL at a time and translate it to .NET, and then alpha and beta testing these, taking what they're calling an "agile" approach to the translation.

    There are already a dozen or so DLLs as part of this application, and my initial job is going to be cutting out more big chunks, making them DLLs as well (in preparation for this "agile" translation).

    During the translation, it's assumed that we'll stay completely 32-bit. However, they desire to ultimately get to a pure 64-bit system. I'm hoping/assuming that it'll be a simple recompile once it's all translated and tested.

    Anyone done this VB6 and .NET interoperability with .NET DLLs? Anyone have an example?
    We do that ALL over the place. Then intent was to keep running VB 6.0 and all new development is in .Net. I'll try and help as you go.
    Please remember next time...elections matter!

  17. #17

    Thread Starter
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    9,852

    Re: VB6 and .NET interoperability

    Ok ok, let me try and provide some more context.

    Yeah, I'm not the one with the purse strings, but I am in a position to make suggestions that are deeply heard. Two weeks ago, we just had a big meeting with about 30 people present, and some progress was made. But I still get ahead of myself.

    First, it's just GOT to be recognized that this is a mammoth program that's been in development for about 20 years (since 1999). It basically assists with human (pediatric) motion and body assessments. To list a few of the things it analyzes: kinematic and kinetic motion during walking, electromyography while walking, standing balance assessments, oxygen consumption while walking, physical examinations for passive range-of-motion, foot pressure analysis during a "step" event, and much more. We call these "services" and many are already separated into DLLs, with more of that work to be done.

    There are several hundred forms in this project, and 1000s of lines of code.

    So, to do a clean-room conceptual rewrite is really out of the question. It really needs to be a translation.

    Also, if we were to attempt to translate it all at once, I personally fear that it'd never get done. It'd just be too big of a job. We've got to find an "agile" path forward which will allow piecemeal translation and testing work.

    ----

    Now, some decisions that have already been made: 1) we're going to .NET, with probably much of it being in VB.NET. I'm not opposed to some C# as well, if it makes sense. It's my understanding that those two work almost seamlessly in Visual Studio. But, a move to pure C++ just seems like too big a jump for us. And also, that opens a big political door. Others in the room all have their "pet" languages. To insist on .NET makes sense to them in that it's supposedly the natural progression from VB6. These options were discussed at the meeting, and that decision is made (and I'm really not willing to re-visit it).

    ----

    Another decision that's been made is that we're going to try and translate with as little change in functionality and appearance as possible. Ideally, we'd be able to slip in translated pieces, and users would be none-the-wiser.

    ----

    Maybe that helps to understand the scope and direction of this project.
    Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.

  18. #18

    Thread Starter
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    9,852

    Re: VB6 and .NET interoperability

    Also, I'm on-site (at a specific client site, not the corporate headquarters) ... and I've got a todo list on my desk. So, I'm not officially on the clock for this translation task at the moment. But, the money ultimately all comes from the same place, so nobody gets upset if I burn a couple of candles at once.

    Having said that, I will be looking at that "codeproject.com" code sometime in the next couple of days.

    But, ideally, what I'd like is a trivial example of a VB6 executable that calls, passes arguments to, and executes a component compiled in .NET (Visual Studio). And, hopefully, ideally, some of those arguments could be instantiated COM based objects. But, as a first step, maybe just some straightforward BSTR and numeric arguments. UDTs will also come into play. When time permits, I'll also be working on these things, and I'll continue to post my progress in this thread.

    Thanks,
    Elroy
    Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.

  19. #19
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Location
    Sofia, Bulgaria
    Posts
    5,120

    Re: VB6 and .NET interoperability

    IMO going for a .Net based desktop app for Windows only is just not worth the effort.

    Now is the time to consider which one will be cheaper in the long run (next 20 years):
    1. .Net based desktop app for Windows
    2. .Net Core desktop app w/ some cross platform UI kit
    3. .Net Core web app
    4. node.js web app
    5. node.js Electron based desktop app for Windows only w/ VB6 integration (not sure if possible)

    cheers,
    </wqw>

  20. #20

    Thread Starter
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    9,852

    Re: VB6 and .NET interoperability

    Hi Wqweto,

    I hear ya, but I just feel compelled to keep this thing manageable. Also, 99% of my work is for a single client with 22 hospitals. And believe me, they are TOTALLY a Windows shop. So, cross-platform really isn't a concern.

    Also, there are basically two concerns driving all of this: 1) they desire to become a pure 64-bit Windows shop in the near future (a couple of years), and 2) they want this application to be in a language that is actively and fully supported by Microsoft.

    Best Regards,
    Elroy
    Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.

  21. #21
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,988

    Re: VB6 and .NET interoperability

    Predicting the future is risky. If anybody can say for certain what the best route forward is, I'd sure like to know.

    When it comes to a translation, keeping the look and feel can be a really good thing, especially if the users like the look and feel. However, what goes on behind that can be altered a bit to try to make it more future-proof...which won't really work, but you can always try, since the future may turn out the way you are hoping. To that end I would say that one focus is isolating parts of the program. This may have already been done, as the program may already be some n-tier design with a great deal of separation between UI and backend, and even some separation of the UI into components. However, if that is not the case, now would be a good time to do as much of that as you feasibly can within the limits you've already set out. After all, the smaller the piece that needs to be converted next time around, the easier the conversion will be.
    My usual boring signature: Nothing

  22. #22
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,988

    Re: VB6 and .NET interoperability

    You've mentioned 64-bit a couple times. Is there some compelling reason for doing that, or is just whim on the parts of the client? In other words, do they have a good reason, or is it just that 64-bit is "modern"?
    My usual boring signature: Nothing

  23. #23

    Thread Starter
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    9,852

    Re: VB6 and .NET interoperability

    Quote Originally Posted by Shaggy Hiker View Post
    You've mentioned 64-bit a couple times. Is there some compelling reason for doing that, or is just whim on the parts of the client? In other words, do they have a good reason, or is it just that 64-bit is "modern"?
    Shaggy, you called it. I've tried repeatedly to make the 32-bit and WoW64 argument ... but, over time, it just falls on more and more deaf ears. It just sounds old and outdated to them, and they're willing (or, rather, insist) on paying to bring things "up to date".

    Also, just to put it out there, everything I do is open-source. The intellectual property issue came up during the recent meeting, and it was made clear that that's not a concern. This organization is entirely beneficent, and it would be absolutely fine (even delightful) if others derived patient care benefit from this work.

    --------------

    EDIT: I just soooooooo wish Microsoft would pull VB6 off the shelf, dust it off, and make it compile 64-bit executables. And also say that they're continuing to support it. (That means little to me, but it means a great deal to my client.)
    Last edited by Elroy; Dec 4th, 2019 at 11:22 AM.
    Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.

  24. #24
    Hyperactive Member
    Join Date
    Mar 2018
    Posts
    460

    Re: VB6 and .NET interoperability

    Quote Originally Posted by Elroy View Post
    Shaggy, you called it. I've tried repeatedly to make the 32-bit and WoW64 argument ... but, over time, it just falls on more and more deaf ears.
    Just add "64bit" to the exe name

  25. #25
    PowerPoster
    Join Date
    Sep 2012
    Posts
    2,083

    Re: VB6 and .NET interoperability

    Hi Elroy, it seems that calling .NET DLLs from VB6 is not a good idea. Perhaps you should consider writing a more beautiful shell (UI) with .NET and then using this shell (UI) to call VB6 DLLs.

  26. #26
    Lively Member Grant Swinger's Avatar
    Join Date
    Jul 2015
    Posts
    71

    Re: VB6 and .NET interoperability

    Have you ordered these two books?

    Name:  Book1.jpg
Views: 923
Size:  22.2 KB Name:  Book2.jpg
Views: 877
Size:  26.6 KB


    Believe me, for a project like this you want both of them on your desk as they have exactly what you're looking for. The books use C# for the examples but you should be able to translate to VB.NET easily.

    You may want to consider using C# anyway. I'm pretty sure that VB.NET will always be around but it doesn't get the love from Microsoft anymore and will always be a poor relation to C#. It can't really be called an "actively and fully supported" Microsoft language anymore. It's heyday was back when I was doing those insurance application conversions because it had superior interoperability with classic VB and was easier to learn for the VB developers I was working with at the time.

  27. #27

    Thread Starter
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    9,852

    Re: VB6 and .NET interoperability

    Quote Originally Posted by dreammanor View Post
    Hi Elroy, it seems that calling .NET DLLs from VB6 is not a good idea. Perhaps you should consider writing a more beautiful shell (UI) with .NET and then using this shell (UI) to call VB6 DLLs.
    Yes, that's an option. However, the base code (i.e., the actual EXE) is currently the largest part of the project. I was trying to avoid translating that to .NET as the first task. If we took that approach, it would require more VB6 preparatory work to try and make that base project as small as possible (cleaving off as much code as possible and creating additional DLLs).

    But dreammanor, I'm curious why you think calling .NET from VB6 isn't a good idea. I haven't looked into it yet, but is there some problem with doing that?
    Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.

  28. #28

    Thread Starter
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    9,852

    Re: VB6 and .NET interoperability

    @Grant Swinger: Those look like excellent books, at least from the titles. I'll look into getting copies.

    EDIT1: I'm encouraged that both books have chapters on both COM-to-.NET interoperability and .NET-to-COM interoperability. This suggests that either can be the driver of all the software.
    Last edited by Elroy; Dec 4th, 2019 at 04:18 PM.
    Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.

  29. #29
    Smooth Moperator techgnome's Avatar
    Join Date
    May 2002
    Posts
    34,531

    Re: VB6 and .NET interoperability

    Quote Originally Posted by Elroy View Post
    But dreammanor, I'm curious why you think calling .NET from VB6 isn't a good idea. I haven't looked into it yet, but is there some problem with doing that?
    I'm curious about that too since it's been my observable experience that it's easier to do than calling VB6 from .NET.

    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  30. #30
    PowerPoster PlausiblyDamp's Avatar
    Join Date
    Dec 2016
    Location
    Pontypool, Wales
    Posts
    2,458

    Re: VB6 and .NET interoperability

    Quote Originally Posted by Elroy View Post
    Yes, that's an option. However, the base code (i.e., the actual EXE) is currently the largest part of the project. I was trying to avoid translating that to .NET as the first task. If we took that approach, it would require more VB6 preparatory work to try and make that base project as small as possible (cleaving off as much code as possible and creating additional DLLs).

    But dreammanor, I'm curious why you think calling .NET from VB6 isn't a good idea. I haven't looked into it yet, but is there some problem with doing that?
    It may be worth trying to implement new functionality as a .Net dll that you can call from VB6 as a starting point, that way you will get the benefits of learning how it works without breaking anything already written. Keep the UI as VB6 for now and if the new functionality requires UI then continue to add UI to the VB6 exe - at least the new logic is in .Net.

    Over time you might start to migrate some of the VB6 dlls to .Net and gradually replace the back end logic, but hopefully keeping most of the UI unchanged.

    Once you have a significant amount of the app's logic ported to .Net then starting to build a .Net front end that uses the existing mixture of .Net / VB6 dlls might allow you to take advantage of the newer UI tooling. Once the UI is pretty much feature parity with your VB6 app then you can start to develop new UI in .Net as well and effectively retire the old UI.

    All new functionality gets implemented in .Net and eventually the last of the VB6 dlls are ported over and no longer needed, hopefully leaving you with a .Net application that meets your requirements. At this point it might just work if compiled as 64 bits, depending on API calls etc. Either way you might spend more time converting the ported code to a more .Net approach (depends on how much of the VB6-ness you retained while porting) and start to take advantage of the new features and capabilities.

  31. #31
    Fanatic Member
    Join Date
    Feb 2017
    Posts
    858

    Re: VB6 and .NET interoperability

    Elroy:

    Found this -- maybe worth a look see.

    http://vbto.net/

    Then convert from NET whatever to VB7 (Net).

    David

  32. #32
    PowerPoster
    Join Date
    Sep 2012
    Posts
    2,083

    Re: VB6 and .NET interoperability

    Quote Originally Posted by Elroy View Post
    Yes, that's an option. However, the base code (i.e., the actual EXE) is currently the largest part of the project. I was trying to avoid translating that to .NET as the first task. If we took that approach, it would require more VB6 preparatory work to try and make that base project as small as possible (cleaving off as much code as possible and creating additional DLLs).

    But dreammanor, I'm curious why you think calling .NET from VB6 isn't a good idea. I haven't looked into it yet, but is there some problem with doing that?
    15 years ago, we did similar work. The biggest difficulty in migrating old large VB6 projects to .NET is how to ensure the stability of the system. Old large VB6 projects are often tested by users for a long time, and stability is its greatest value.

    .NET is used as the UI shell/layer and calls VB6 DLLs, which means that the core data and business logic still use VB6, which can ensure the stability of the new system as much as possible. In addition, doing so also means that the old VB6 project must undergo some preliminary transformations, that is, the separation of the UI from data and business logic. In addition, it is necessary to migrate the Access DB to MS SQLServer.

    When the above work is completed, a "new application" in the skin of the .NET is presented to the users, and it'll run well. This will show that your migration has not failed, maybe it's not perfect.

    When the users have a new system that is running steadily, if you want to completely abandon the VB6 source code, then use C# to completely rewrite the VB6 DLLs with a new software architecture (though this does not make any sense, because now it's been 9102, and .NET is neither new nor best, and VB.NET seems to be a joke).

    Note: Our software has been transformed for 10 years, but what our users like most is still the old software developed with VB6. The new software is gradually abandoned by users and our company. Because in the windows desktop environment, VB6 can do almost any work of .NET, including a cool UI.

    At present, the most perfect solution to deal with old large-scale VB6 projects is still Olaf's solution, but few people have such rich and comprehensive programming knowledge and skills as him, so few people can still use a lot of VB6 code in the Web, Mobile and Cloud environments. I'll spend a lot of time learning how to migrate my VB6 programs to cloud services.
    Last edited by dreammanor; Dec 5th, 2019 at 12:58 AM.

  33. #33
    PowerPoster
    Join Date
    Feb 2006
    Posts
    24,482

    Re: VB6 and .NET interoperability

    Isn't VB.Net at version 16 or so right now?

  34. #34
    Wall Poster TysonLPrice's Avatar
    Join Date
    Sep 2002
    Location
    Columbus, Ohio
    Posts
    3,834

    Re: VB6 and .NET interoperability

    I'm attaching a quick and dirty example of a VB 6.0 project calling a VS 2013 .Net program that when you click the VB 6.0 command button it calls the .Net code that displays "Hello". My instructions aren't the greatest but it should work as documented and let me know if it doesn't.
    Attached Files Attached Files
    Please remember next time...elections matter!

  35. #35
    Fanatic Member
    Join Date
    Jun 2019
    Posts
    557

    Re: VB6 and .NET interoperability

    We've done "VB6 using .NET libraries" many times in several projects for the last 15 years. No problems found so far. Actually one of the projects from last year (fully written in VB.NET with VS2017) has COM library which is used by our old VB6 apps.

    Also in some of our projects some applications are written in .NET which use VB6 library which uses another .NET library. Or the main app is VB6 executable where .NET COM objects are used and these .NET classes use other VB6 ones. In general such mix is not a problem.

    .NET gives the ability to utilize better the actual hardware - multi-core CPUs, 32GB+ memory, the generated JIT code use the proper instructions provided by latest generations of CPUs (e.g. different variants of AVX instructions). On GitHub there are thousands of new and extremely performance optimized libraries which no one will create for VB6.

    With a little effort in C# or VB.NET we can bring such functionality and performance in a COM library which VB6 apps can take advantage of.

    Creating .NET COM library is easy with following steps (a bit shorter than the ones Tyson wrote in his document):
    • In VS.NET create new VB .NET Framework library
    • Add new class and in the dialog select COM Class
    • VS will create the class with the right attributes for COM classes with all GUIDs generated
    • Check in project properties in Compile tab if Register for COM interop is checked

    Something that is a bit annoying is that you have to pay attention on variable types due to some small differences in VB6 and .NET, e.g. VB6 Long will become Integer in .NET (found this in a quick search: data types in VB6 and .NET)

  36. #36

    Thread Starter
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    9,852

    Re: VB6 and .NET interoperability

    @TysonLPrice, thanks. That document is truly great!

    Name:  NetTest.png
Views: 927
Size:  4.6 KB

    This is at least the beginnings of a road-map on how to do this. When I get time, I'll start exploring how to pass arguments into VB.NET, hopefully including COM object variables.

    I'd zip up and attach this test, but I'm not sure what to zip on the .NET side. Just for this little test, I wound up with 33 files and 13 folders (not counting the hidden ones). On the VB6 side, there are 2 files in a single folder.

    @peterst, thanks for the link. It's curious to me why we lost the Byte and Date types. I make extensive use of both of those, and, with Byte, it's often an array. I suppose I'll have to build a class in .NET to recover those.

    @dreammanor, yes, stability is my biggest concern. This VB6 project is just so crazy bullet-proof from all the years of use, that's why this is somewhat difficult to me, and why I'm shouting for alpha-testing and beta-testing to be a large part of this, at least until we get comfortable with what we're doing.

    @vb6forever, thanks for the link, but that's a bit down the road from where we are right now. First step is just to get the theoretical road-map figured out. Once that's done, we'll actually start figuring out the translation.
    Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.

  37. #37
    Smooth Moperator techgnome's Avatar
    Join Date
    May 2002
    Posts
    34,531

    Re: VB6 and .NET interoperability

    Byte is still there.... it's even still listed in the chart...it's just under .NET not VB.NET because VB doesn't have a unique specific one like it does for some of the others. As for the Date... there's a DateTime.... it's the samething, but with some added stuff (like time and additional functions and methods) but essentially it's the same.

    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  38. #38

    Thread Starter
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    9,852

    Re: VB6 and .NET interoperability

    Quote Originally Posted by techgnome View Post
    Byte is still there.... it's even still listed in the chart...it's just under .NET not VB.NET because VB doesn't have a unique specific one like it does for some of the others. As for the Date... there's a DateTime.... it's the samething, but with some added stuff (like time and additional functions and methods) but essentially it's the same.
    Ahhh, it's good to know that Byte is still there. Regarding Date, I have a bad habit of knowing it's basically a Double in VB6, and using that knowledge to get certain things done. I'm quite sure that will no longer work with the .NET DateType type. I guess all of that code will have to be examined and reworked.

    Having some unsigned stuff will sure be useful. I've often ached for that in VB6.
    Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.

  39. #39
    Wall Poster TysonLPrice's Avatar
    Join Date
    Sep 2002
    Location
    Columbus, Ohio
    Posts
    3,834

    Re: VB6 and .NET interoperability

    I'll start exploring how to pass arguments into VB.NET
    Here is an example built using the same methodology:

    VB 6.0 passing the hello text:

    Private Sub Command_Click()
    Set mVBForums = New VBForums.Main
    Call mVBForums.SayHello("Hello")
    End Sub

    .Net

    Form1
    Public pTExt As String
    Public Sub SayHello(ByVal pText As String)
    mForm1.pTExt = pText
    mForm1.SayHello()
    End Sub

    Class:


    Public Sub SayHello(ByVal pText As String)
    mForm1.pTExt = pText
    mForm1.SayHello()
    End Sub
    Please remember next time...elections matter!

  40. #40
    Smooth Moperator techgnome's Avatar
    Join Date
    May 2002
    Posts
    34,531

    Re: VB6 and .NET interoperability

    Quote Originally Posted by Elroy View Post
    Ahhh, it's good to know that Byte is still there. Regarding Date, I have a bad habit of knowing it's basically a Double in VB6, and using that knowledge to get certain things done. I'm quite sure that will no longer work with the .NET DateType type. I guess all of that code will have to be examined and reworked.

    Having some unsigned stuff will sure be useful. I've often ached for that in VB6.
    Yeah... depending on what you're doing, some of it will need to change.... one thing that will is if you're doing things like this: date1 - date2 ... and expecting a double in result.... that no longer happens... what you get now is what is called a TimeSpan object... which may or may not be more useful than a plain double, as it has .Minutes as well as .TotalMinutes methods (which may or may not be the same value) and other methods.

    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width