-1

I have taken over VB6 product that utilises a large C# (.NET 2.0) component via COM-interop.

I would like to if possible downgrade the C# component (Winforms) to VB6 in order to remove the COM-interop layer.

Does a converter exist to do this?

CJ7
  • 22,579
  • 65
  • 193
  • 321
  • 2
    Do you mean the .net WinForms library? If so, it isn't a case of just converting the C# code, but also replacing any use of the .net framework. – Douglas Feb 08 '12 at 00:45
  • 1
    Not really possible. Can we ask why you would want to do this? – iandotkelly Feb 08 '12 at 00:45
  • 4
    Not that I've seen. You'd likely be better off upgrading the VB6 code (no matter the code base size). VB6 is on its way out, keep your code looking to the future. – M.Babcock Feb 08 '12 at 00:46
  • 3
    Try to run your VB6 on Win7/64 and then reconsider. – Eugen Rieck Feb 08 '12 at 00:47
  • 2
    @EugenRieck: it installs and runs fine, even on 64-bit. MS has said Win7 will support VB6 apps. I don't know why your comment was upvoted. – CJ7 Feb 08 '12 at 00:49
  • 3
    I suspect that your only option would be to manually do this; even the VB6 -> .NET converters are only so good when moving from a relatively restriced VB6 environment to a more robust .NET platform. You are attempting to go backwards and across a syntactical difference by throwing C# into the fold. Out of curiosity, what problems are you facing with COM-Interop? It may make more sense to tackle those issues or perhaps bring the other component forward into .NET. You may want to refer to the statement on VB6 support before you commit to it: http://msdn.microsoft.com/en-us/vstudio/ms788708 – codechurn Feb 08 '12 at 00:51
  • 1
    It would be useful know know why you want to do it this way rather than just 'in order to remove the COM-interop layer' which is rather pointless as an objective in itself. – iandotkelly Feb 08 '12 at 00:52
  • @CraigJ you are lucky then: Lots and lots (most, maybe all) of VB6 apps I have had the "pleasure" to force to run on Win7/64 have had some hiccup or some other. Might depend on which compinents you use. – Eugen Rieck Feb 08 '12 at 00:53
  • 1
    @Art: doesn't that link confirm that VB6 apps will be supported by Win7/Win8? – CJ7 Feb 08 '12 at 01:03
  • CraigJ - are you going to answer mine and @Art's question about why you need to do this - what issues are you having? – iandotkelly Feb 08 '12 at 01:06
  • @iandotkelly: see the question. The COM-interop makes development and deployment more difficult. Are you saying if you had a choice you would choose a COM-interop solution over a single-platform solution? (I can't even have events pass between the two layers without running into all sorts of problems.) – CJ7 Feb 08 '12 at 01:07
  • @CraigJ The core VB6 runtime files will be present on Windows 7 / Windows 8, however the VB6 IDE is not being supported any more. If you need to change the application, you will be doing so using an IDE which is not supported. I am not aware of any other other way to compile a VB6 app unless you use the VB6 IDE. – codechurn Feb 08 '12 at 01:08
  • 1
    I did see the question. If this wasn't a legacy application I would certainly look at a single platform - but if I have 1 legacy platform nearing EOL and 1 slightly out of date platform - if they are working I really wouldn't look at messing with them too much. You seem to be responding to questions rather defensively - we just want to know more detail so we can help. If you can't be bothered providing that detail then, meh. – iandotkelly Feb 08 '12 at 01:11
  • @Art: I have been able to install the IDE on Win7. Win7 can automatically detect what compatibility mode is needed and then it uses that thereafter. Not ideal, but it works. In any case, I generally use XP to develop. – CJ7 Feb 08 '12 at 01:12
  • @iandotkelly: the main reason for wanting a single layer is because there are "cold start" type delays with COM-interop. I've already had to "invisibly" load a C# form during the splash just to avoid a unacceptably long delay when this form is first opened in the app. It is also difficult to pass events between the two layers. My preferred approach to dealing with a legacy product is to have rewrite project running simulatenously, rather than having a hybrid product. I suspect the previous developer was desperate to gain some .NET experience. – CJ7 Feb 08 '12 at 01:16
  • 2
    Well the strict answer to your question is 'no there is no code converter'. You are the only person that knows your product, it might be worth the effort of rewriting the .NET component in VB6, but you should assess whether the effort might best be rewarded by moving to a completely .NET platform - gaining years of support on the platform, and you might find it easier to find developers. In terms of development and deployment issues, it is a far easier environment to work in - compared to DLL hell of VB6 – iandotkelly Feb 08 '12 at 01:19
  • @iandotkelly: I have found that a good self-heal MSI installer does deal with the DLL issues. – CJ7 Feb 08 '12 at 01:21
  • Your choice - it sounds like you are spending a lot of effort engineering your way around the issues of a legacy platform. VB6 was starting to become outdated in 2000 (the last time I used it). In terms of developers - you might find people willing to work in VB6 start to become either very expensive or not very good. – iandotkelly Feb 08 '12 at 01:24
  • 1
    Didn't read all the comments (and not going to), but it very much sounds like you're going the wrong way. The COM interop layer is a very handy thing, indeed! Keep things the way they are if they're working, and slowly migrate your VB 6 code to C#, using the same mechanisms to utilize it. VB 6 is a dying language, and I say this as someone who knows it quite well without any snark or bigotry implied. If you're going to dedicate time and effort into something, dedicate that time into writing *new* code in a new, supported language. Remember, VB.NET and C# interop *seamlessly*. – Cody Gray - on strike Feb 08 '12 at 03:15
  • @EugenRieck VB6 applications work on Windows 64-bit and [Microsoft even support the VB6 runtime](http://msdn.microsoft.com/en-us/vstudio/ms788708.aspx) on Windows 64-bit. Your comment is downright wrong and you should consider deleting it. – MarkJ Feb 08 '12 at 09:19

2 Answers2

2

I don't think it is possible due to very different nature of these platforms.

Alexey Raga
  • 7,457
  • 1
  • 31
  • 40
  • Not only that, "C#" is a moving target and you have to ask "which C#?" However the question was tagged ".net-2.0" so that narrows the field. Still, a converter would have to be hydra-headed to be very successful. – Bob77 Feb 08 '12 at 02:40
  • 2
    To expand on Bob's comment, lots of different versions of C# support .NET 2.0. The language version is not tied to the version of the target framework. But this answer is still basically true: the absence of the .NET Framework libraries will make 'back'-porting any C# code to VB 6 basically impossible, or at the very least an exercise in masochism. You'll be rewriting the entire BCL in VB 6, not my idea of a fun way to spend a couple of months, and you won't have very much to show for it when you get done! – Cody Gray - on strike Feb 08 '12 at 03:17
0

I think your best bet would be to use a code converter to go from c# to vb .net.

Google: "c# to vb .net"

You could probably even get this compiling and working as an intermediate step.

Then you try to plop it in VB6 and "make it work".

A lot of people are complaining about why you would want to do this... they have a point, but this is how I'd get it done. Although, I'd much rather move the VB6 code to VB .NET :)

Derek
  • 7,615
  • 5
  • 33
  • 58
  • What do you mean by plopping it into VB6? How will the VB6 IDE understand the code? – CJ7 Feb 08 '12 at 03:12
  • My point is that VB .NET is a lot closer to VB6 than c# is. You still would have to do a lot of work to get it working. – Derek Feb 08 '12 at 03:15
  • 3
    A VB.NET converter really isn't going to get you very far. The VB.NET syntax is appreciably different from that found in VB 6. Sure, you'll get the variable declarations right, but that's probably about it in a non-trivial code base. And not to mention the .NET library that won't exist in VB 6, which means that even though your syntax is properly converted, the code won't compile or do anything useful. – Cody Gray - on strike Feb 08 '12 at 03:16
  • public function, public sub, if... then.. end if You get closer, but I agree there is a lot of work left to do :) – Derek Feb 08 '12 at 03:19
  • @CodyGray: I don't see it conceptually being any different to the Vb6 to .Net converters. If you can one way you should be able to go the other. But I guess there's no reason why any company would bother to create a reverse converter. – CJ7 Feb 08 '12 at 03:21
  • @Derek: I was hoping there would be something that converted the Forms back to Vb6 forms. It's theoretically possible but apparently no one has seen it as worth doing. – CJ7 Feb 08 '12 at 03:24
  • 2
    @CraigJ: The difference is that there are a whole heck of a lot of things provided by the .NET Framework that simply don't exist in VB 6. You can translate from VB 6 to VB.NET or C# because the .NET Framework includes nearly all of the VB 6 stuff plus *more*. You can't go backwards without reinventing a whole lot of stuff. Your comment to Derek seems to suggest that you're hoping someone has reimplemented all of the `System.Windows.Forms` libraries in VB 6, which I *suppose* is theoretically possible, but simply not going to happen. – Cody Gray - on strike Feb 08 '12 at 03:26
  • @CodeGray: I don't see it as a matter of reimplementing all the libraries, I just see that the initial GUI design of a Form should be easy to tranlsate across languages because it's simply having GUI elements at certain positions on a form. If there are .NET classes and functions that have no equivalent in VB6 then obviously that is a problem but I would have thought the basic stuff should be convertable. I could then fill in the rest. – CJ7 Feb 08 '12 at 03:36
  • I agree that this is about as much automation of the process as you are going to find using any off-the-shelf tool. With enough motivation to undertake this process it might be helpful at least as a guide instead of trying a direct port by hand. – Bob77 Feb 08 '12 at 04:40
  • 3
    The "best bet" is not to do it at all. – MarkJ Feb 08 '12 at 10:52