I agree. We already have had to deal with the issue of how to explain to your clients who are downloading the software on how to get the .NET environment for older PCs. In VB 6.0 it was much simpler (just wrap up the runtime libraries and off you go). In fact, VB.NET is so different that is almost another language entirely. Before designing a new piece we now have to consider which version of VB is more appropriate for this use. While we try to work mostly with .NET, occasionally good old VB 6.0 is the better choice.

Yehuda

There is some good reading here. I probably didn't say things right and I hesitated to write anything at all about VB versus C. I just get tired of hearing all the flack making VB programmers something less than a C programmer.

I have seen bad code written in VB and bad code written in C. I think what programmers need to concentrate on is a development methodology and the application of available technologies. Like OOP, COM, XML and the like. Personally, I like the hybrid approach let C do what it is good at and let VB do what it is good at.

I can agree with much of what is being said about .NET. But I do think the Internet model, if you will, is upon us. We work on the internet/intranet and the local PC and the transition becomes more seamless all of the time. XML seems to be here, been here, and I have to admit I am behind the power curve.

With the current software I really like the ability to share code with COM objects. I am not sure if you can share the .NET libraries with a VBA application for example. Most of the industrial controls HMI software has VBA and for us to be able to reference a library versus rewriting code is a great benefit. Even though it is not optimized the libraries can be access in .NET as well. So, I see continuing VS 6.0 for a little while longer but still migrating towards .NET.

What I was implying by leveling the playing field with .NET is that if one chooses to write a code module in C# and another in VB.NET they can easily be integrated. From the looks of things the syntactical differences are minor so moving from one to the other should not be much trouble. Currently, what I see as the biggest obstacle to working in C or VB is not how well the application will perform, or what is more productive but what we know. Usually an application is developed exclusively in one language or another. My hope is that we can focus our efforts on solving problems and improving our product and not spending a lot of time trying to determine which language the solution will be written in.

There I have probably said too much and yet not enough.

I really appreciate all of your comments.



Larry Asher

Larry,

You don't need to share the .NET libraries for VBA. VB.NET can put a COM interface on an object s o as to allow it to be used through COM as well as through .NET

Larry & Yehuda,

Just as a note. You have more steps to manage GUIDs for the .NET exposed COM interfaces, but wrox has a GREAT book about VB.NET and COM interaction. The book explains it well, and gives good advice on how to go about it. I have to admit, I have read the book, but haven't really worked on an Interop project.

Book Info:
Professional Visual Basic Interoperability - COM and VB6 to .NET by Billy Hollis, Rockford Lhotka





John R Lick
[email protected]