locked
Reccomendation of best solution to extend our applicaiton using VB.NET RRS feed

  • Question

  • hello - and thank you for your time. First a little back-ground.

    We have a legacy system that is written in VB6 and uses the VBScript very extensively as a way of extending this system (500,000 plus lines of code). We are slowing planning a migration to VB.NET but have found many issues where the VBScript code cant be backward compatible with the new .NET classes.

    One option would be to implement a new system in the existing VB6 application to be able to convert VBScript to VB.NET. The way this would work is that we would go to the VB6 application and one of the VBScript modules and upgrade this one VBScript Module to VB.NET. The code changes are not extensive for this change. This would be like an integrated development environment and within VB6 and it would store the compiled .NET class and use interop to access the .NET object much in the same way as it currently access VBScript. This would be great as the new .NET codebase for the upgraded VB6 core application would be fully backward compatible with the re-written converted vb.NET class and during the transition phase it would also provide a performance boost to the old VB6 application.

    QUESTION:

    If I was to proceed with this development, what is the best way to develop this VB.NET code within the VB6 environment?? I know how to compile and create the code - but my question relates to the best to way to get my people to write the VB.NET code.

    In it's simplest form it could a text editor to write the VB.NET code.

    But I was thinking that a custom project type in VS2010 might be better. From VB6 you would click a button that would open a VB.NET project - edit it, make changes and when done upload it back into the VB6 application?? Might even be able to debug from this location??

    Can anyone offer any advice as to this type of project, where to start and if this sounds practical??

    Thanks very much for your help


    matvdl

    Saturday, February 9, 2013 3:56 AM

Answers

  • Hi matvdl,

    Forget the migrate, re-design them all.


    Ghost,
    Call me ghost for short, Thanks
    To get the better answer, it should be a better question.

    • Marked as answer by Ego Jiang Friday, March 8, 2013 9:13 AM
    Monday, February 11, 2013 8:40 AM
  • Unfortunately, his response is accurate. What you are describing sounds like it would entail almost as much work as just reimplementing your application/solution from the ground up. VB6 is so far out of date it isn't funny. And there is zero support for it from Microsoft.

    The VB6 IDE isn't that extensible from the get go, so attempting to introduce a new editor scenario in that IDE isn't doable. While you could theoretically have a button in the VB6 IDE that could launch the VS2010 IDE, and possibly use a custom project type and build a .NET assembly. There is no facility that would "add" this assembly to your VB6 project. VB6 compiles down to a native binary, and the only way you'd interop with it, would be via COM automation.

    Ultimately, I cannot think of a reasonable transition here, where your scripting modules would be converted to VB .NET (and still work with your VB6 application). But first and foremost is that you run a huge risk in that if you hit any sort of problem with your modified VB6 application, you have no way to remedy it through Microsoft (via technical support, patches, etc). That's a large enough risk for a project of that magnitude that is should probably be removed from consideration.

    Sincerely,


    Ed Dore

    • Proposed as answer by Ego Jiang Friday, March 8, 2013 9:12 AM
    • Marked as answer by Ego Jiang Friday, March 8, 2013 9:13 AM
    Wednesday, March 6, 2013 3:43 AM

All replies

  • Hi matvdl,

    Forget the migrate, re-design them all.


    Ghost,
    Call me ghost for short, Thanks
    To get the better answer, it should be a better question.

    • Marked as answer by Ego Jiang Friday, March 8, 2013 9:13 AM
    Monday, February 11, 2013 8:40 AM
  • that is really not a helpful answer at all,

    matvdl

    Tuesday, March 5, 2013 10:31 PM
  • Unfortunately, his response is accurate. What you are describing sounds like it would entail almost as much work as just reimplementing your application/solution from the ground up. VB6 is so far out of date it isn't funny. And there is zero support for it from Microsoft.

    The VB6 IDE isn't that extensible from the get go, so attempting to introduce a new editor scenario in that IDE isn't doable. While you could theoretically have a button in the VB6 IDE that could launch the VS2010 IDE, and possibly use a custom project type and build a .NET assembly. There is no facility that would "add" this assembly to your VB6 project. VB6 compiles down to a native binary, and the only way you'd interop with it, would be via COM automation.

    Ultimately, I cannot think of a reasonable transition here, where your scripting modules would be converted to VB .NET (and still work with your VB6 application). But first and foremost is that you run a huge risk in that if you hit any sort of problem with your modified VB6 application, you have no way to remedy it through Microsoft (via technical support, patches, etc). That's a large enough risk for a project of that magnitude that is should probably be removed from consideration.

    Sincerely,


    Ed Dore

    • Proposed as answer by Ego Jiang Friday, March 8, 2013 9:12 AM
    • Marked as answer by Ego Jiang Friday, March 8, 2013 9:13 AM
    Wednesday, March 6, 2013 3:43 AM