Hi,

Anyone have a URL at the msdn who explain the differences of the VB6 to
vb.NET ??

Regards,
Rodrigo

I like Bob Butler's site at
http://home.earthlink.net/~butlerbob/VBNet/index.htm

--
Kathleen
(MS-MVP)
Reply in the newsgroup so everyone can benefit
--

Almost the same as betwwen C and C++...

A lot have exactly the same syntax, but
it is two different languages.

Try http://msdn.microsoft.com

Dag.

Bob is slanted against VB.NET.

I've found that, for any reasonably skilled programmer, writing programs in
VB.NET is not complicated. If you're a beginning programmer, or used to
leaning heavily on many of VB6's crutches, you may have more difficulty (but
no more than you would have learning any new language).

Anyway, none of this answers your question.

You might be interested in the current .NET show
(http://msdn.microsoft.com/theshow/) as it's about upgrading from VB6 to
VB.NET.

This page (http://msdn.microsoft.com/vbasic/technical/upgrade/default.asp)
gives many links on the topic you're interested in.

Finally, a fairly short list that gives the major points:
http://msdn.microsoft.com/vstudio/nextgen/technology/language.asp

I'm honored.

I forgot to add that since the dotnet platform will not run under Win95 I
can't plan to do much, if any, client-side apps for at least a year because
it'll be that long before the majority of my "customers" are on NT 4.0 or
higher.  That limits my dotnet use to server-side only for the immediate
future.  On the plus side, server-side use eliminates, or at least reduces,
several of my concerns regarding resource usage and installations since it's
a controlled environment.

Yes, I do have a bias against it but I've tried to keep the stuff on the web
page as unbiased as possible except where explicitly noted as opinion and
it's not always easy.  If there's anything incorrect point it out and I will
fix it.  If there's something you think is opinion but not clearly marked as
such let me know that too.  My goal with the site is to help VB6 developers
see how to do things they do now "the VB.Net way" without the hype that MS
(understandably) puts on it.  (and also to help myself since I learn best by
trying things out for myself)

There are many good things about VB.Net but it's not all good.

FWIW, I agree with that except, possibly, for the parenthetical phrase.  I
think many who rely on VB6's crutches now, and who copy & paste code from
the web without understanding it, are goingto have a lot of trouble
understanding VB.Net.

Some of the issues I have with VB.Net are:

* many of the syntax incompatibilities with VB6 are not justified (IMO of
course)
* I dislike the GC model,especially for client-side apps, since I see it as
wasting too much resources (and I'm too much of a low-level control freak to
be happy letting the system clean up after me <g>)
* it went way overboard with the OO aproach in a lot of places (working with
DirectoryServices I see that a lot)
* it goes overboard with the side-by-side execution answer to DLL hell
* MSIL code has to be distributed making reverse-engineering too easy
* Edit/Continue and the immediate window are severely crippled (at least for
V1)
* except for trivial apps, existing code needs to be re-designed in too many
cases
* I see no long-term future for it since it is essentially identical to C#
* I'm concerned that in 2-3 years some new VB# will come along and all
existing code will be trash again

Given the average skill level of the VB developers I know, I don't think
many are going to leverage the power of the platform anywhere near as much
as they could.  The shame of it is that I think much of that power could
have been added to VB and made more accessible to a much wider range of
developers.

I guess the big difference is that (don't take this wrong.. I hate labelling
myself, because I'll inevitably say something stupid) I'm very above-average
for a VB programmer. I've never wanted to do anything in VB that I couldn't
find a way to do (and I never use 3rd party OCXs).  The new power that
VB.NET provides is EXACTLY what I've been wishing for for a long time. I
guess that means that I'm more willing to accept the other annoyances in
return for what I percieve as exactly what the language needed.

Well, I would be inclined to say that VB6's incompatibilities with the rest
of the world were not justified, so removing some of them doesn't bother me.

I haven't come across a situation yet where the GC made a difference to me,
so I guess I can't complain about that. However, deterministic finalization
is the stuff holy wars are made of ;)

I haven't worked with DirectoryServices, so you could very well be right
about that. However, OO or non-OO, it's just different ways of looking at a
problem, you may prefer one or the other, yet neither is "wrong".

You could pre-JIT your code to solve that problem, but then you'd loose any
machine-specific optimizations that might be possible.

This is true, and I thought that it would bother me, but it turns out that I
manage just as well without it.

Very true. Those trying to port large applications will not be happy.
Instead of trying to convert, wait until the next major revision and
rewrite. I've been amazed at how much easier things get in .NET because of
the base classes (but it depends largely on what you're doing).

Since it's essentially identical, why shouldn't it have a future?

There's always that risk, no matter what your preferred language.

<cut>

Pre-jit, even if available, doesn't help.  The IL code is still there.

<cut>

Yes, but what happens when VB6 is no longer supported and you can't upgrade
legacy apps to a supported platform?  What happens in a few years when VB#
comes out and is just as incompatible with VB.Net as VB.Net is with VB6?  I
have no problem scrapping and rewriting an app because I've decided that it
can be done better a new way.  I have strong objections to being left
without a reasonable upgrade path and being force to rewrite.

Why should MS continue to devote resources to supporting two languages with
nearly identical feature sets and target audiences?  If/when they decide to
drop one is it more likely to be C# or VB.Net?  I've recently heard vague
rumors that MS is going to let the languages grow apart and look at adding
more technical features to C# and concentrate on ease of use in VB.Net.  If
so, I think that gives VB.Net a future but leaves us where we are now with a
Basic-style language that is easy to use but lacks power and a C-style
language that has the power but is more difficult to use.

Personally, I think MS should bite the bullet, pick one language and run
with it.

True.  I just see it as a much greater risk in the case of VB.Net than other
choices.

Maybe putting it a different way would help clarify what I'm saying:

looking at the product MS is calling "VB.Net" I mostly like the language,
and the platform, and I see a lot of potential and opportunites.  There's
more power there than most VB developers (at least the ones I know) will
ever tap into and there's a lot that would make my life much easier.

looking at it from a VB perspective I see VB.Net as a total bastardization
of the language and I wonder how MS could have so little respect for the
investment their customers have in the language; it makes me very hesitant
to trust where VB.Net, or anything else MS does for that matter, is going.
VB could have been given access to the dotnet platform without making all of
the source-level language changes.  I look at C++ and the managed extensions
that let existing C++ apps leverage existing code while integrating the new
stuff and wonder why a similar approach would not have been appropriate for
VB.  In my more cynical moments I suspect it's because MS has no significant
investment in VB as a language for their own application development so
rewriting existing VB apps is a minor concern to them.

Right now I'm waiting for the VS.Net release since that's when I expect
larger numbers of existing VB users to get it assuming it's going to be an
extension to what they already know.  I doubt the majority has taken the
time to really look into what's coming yet.  Whatever happens, it's going to
be an interesting ride! <g>

Microsoft is adressing this even now.  There should be something up on
www.gotdotnet.com soon about the obfuscator they are going to release.

Dan

I've heard that, and I'm waiting to see what it does when it is released.
Since it is vaporware right now there's no way to judge it's effectiveness.
Overall I don't see obfuscation as a real solution but it may be good enough
for many people.

On Fri, 24 Aug 2001 13:15:30 -0700, "Bob Butler"

I see the need for an obfuscator only as evidence of a very poorly
designed product. The fact that they have to come out with bolt-on
security is proof that they never put enough effort into the original
design. Mind you, Microsoft have had a lot of eXPerience lately with
bolt-on security!

MM