Main Advantages i get when i do a stand alone app in .Net rather than in VB.

P

Punya Narra

Hi All,

I have a choice of using VB and .Net in developing a standalone load
distribution application. I need to provide a case study on what are the
major advantages of using .Net with respect to VB?

Looking forward for a reply

Thanks,
Punya
 
I

Itai Raz

- .Net has better performance (VB is not a performance oriented language).
This requires a benchmark of the typical operations which your program is
going to do, but I'm pretty sure .Net will be superior.
- .Net is more flexible in the sense that no registration of dlls in
necessary.
- VB used to have one big advantage over other languages - it is rapid to
develop with. .Net however, is as fast as VB when it comes to rapid
development, and therefore the only advantage that VB had is no longer
relevant (you can use VB.Net and your code will end up looking pretty much
the same as your VB code).
- .Net is OO, whereas VB has only partial support for OO (for whatever
that's worth in your program - I don't know).
- Installation of .Net programs is easier than installation of VB programs.

Other advantages of .Net over VB can be found in the documentation.
Specifically look for what's new between VB6 and VB.Net, and I'm sure you'll
bump into things. In general, I don't really see any advantage in using VB
over .Net (especially if you're using VB.Net). If you were to write a new
program (which is what you seem to be doing), then .Net would be your choice
in the MS environment, unless you have the need for unmanaged code (in which
case you'd go with VC++...)

Hope this helps, somewhat.

--itai
 
R

Richard Grimes [MVP]

Itai said:
- .Net has better performance (VB is not a performance oriented
language). This requires a benchmark of the typical operations which
your program is going to do, but I'm pretty sure .Net will be
superior.

Yup, the C++ team are responsible for the JIT compiler and they know a lot
about code optimization! VB.NET code takes as much advantage of this as any
other .NET language.
- .Net is more flexible in the sense that no registration
of dlls in necessary.

This is the so-called 'XCOPY deployment'. It works in some cases, but there
are far too many cases when it does not apply, so I regard 'XCOPY
deployment' as Microsoft hype.
- VB used to have one big advantage over other languages - it is
rapid to develop with. .Net however, is as fast as VB when it comes
to rapid development, and therefore the only advantage that VB had is
no longer relevant (you can use VB.Net and your code will end up
looking pretty much the same as your VB code).

This is true of C# too. The OP does not mention the .NET language that will
be used.
- .Net is OO, whereas VB has only partial support for OO (for whatever
that's worth in your program - I don't know).
- Installation of .Net programs is easier than installation of VB
programs.

- increased security, your code is tamperproof, it won't run code that has
not been specified as trusted by your machine's addministrator. 'Trusted' is
fine grain, so there are levels of trust. Code access security checks the
execution stack, so if your code is trusted but is called by untrusted code
the privileged action will be prevented, if your trusted code calls
untrusted code, their privileged actions will be prevented.
Other advantages of .Net over VB can be found in the documentation.
Specifically look for what's new between VB6 and VB.Net, and I'm sure
you'll bump into things.

But please be aware that VB.NET is not VB. You cannot compile VB classic
code under the VB.NET compiler and there are so many other differences that
is is not fair to say that moving from VB classic to VB.NET is simple. It is
not, and you'll find that moving to C# is no more effort. I write in C#,
VB.NET and managed C++, learning .NET was the most important bit, the actual
dialect of the language wasn't too hard (although I admit for most managed
C++ will be a bit harder to learn than the other .NET languages).
In general, I don't really see any advantage
in using VB over .Net (especially if you're using VB.Net). If you
were to write a new program (which is what you seem to be doing),
then .Net would be your choice in the MS environment, unless you have
the need for unmanaged code (in which case you'd go with VC++...)

I agree.

Richard
 
I

Itai Raz

"Richard Grimes [MVP]" <read my sig> wrote in message


This is the so-called 'XCOPY deployment'. It works in some cases, but there
are far too many cases when it does not apply, so I regard 'XCOPY
deployment' as Microsoft hype.

I'd have to disagree with the disagreement. True, there are cases where
you'd have to register your .Net dlls with the GAC, and true - when doing
interop with ActiveX the registration becomes even more of a pain than it
used to be. However, when doing pure .Net, the xcopy deployment, for me,
turned out to be most convenient and working suprisingly flawlessly. If you
take for example Desktop applications, Console applications and even ASP.Net
applications, the xcopy thing is just plain WORKING. The first time I took
all of my files in an ASP.Net application and just dumped them over the old
ones, only to watch everything working flawlessly afterwards, it felt like I
just got the bar;bar;bar on the slot machine!
This is true of C# too. The OP does not mention the .NET language that will
be used.

...and neither did I...
- increased security, your code is tamperproof, it won't run code that has
not been specified as trusted by your machine's addministrator. 'Trusted' is
fine grain, so there are levels of trust. Code access security checks the
execution stack, so if your code is trusted but is called by untrusted code
the privileged action will be prevented, if your trusted code calls
untrusted code, their privileged actions will be prevented.

Thanks for the addition, although I found that in many cases these new
features serve as a burdon on the new .Net programmer, rather than an
advantage. (and then you hear the smart puppy go "I just went into the
wizard and gave all the assemblies in the world full trust", which kind of
defeats the purpose in my mind).
But please be aware that VB.NET is not VB. You cannot compile VB classic
code under the VB.NET compiler and there are so many other differences that
is is not fair to say that moving from VB classic to VB.NET is simple. It is
not, and you'll find that moving to C# is no more effort. I write in C#,
VB.NET and managed C++, learning .NET was the most important bit, the actual
dialect of the language wasn't too hard (although I admit for most managed
C++ will be a bit harder to learn than the other .NET languages).

I have found that MS agrees with your approach, but they only reached to
this enlightment much later in the process of developing .Net. I have
therefore found that the best articles for people who want to know "what's
new" in .Net are those Dr. GUI type articles that were written when VB.Net
was still known as "the next version of VB" or VB7. In those articles they
just bring out plain differences between VB6 and VB.Net, without going
through what I personally consider as a lot of buzz-words describing why
VB.Net is NOT the next version of VB6, but rather a new language. Let's be
honest - if you're a VB6 programmer (who doesn't regularly write in C, C++,
Java, etc.), you simply don't want to hear this "new language" talk while
you're trying to gain some progress in your carreer and move on into the
future.


--itai
 
R

Richard Grimes [MVP]

Itai said:
I'd have to disagree with the disagreement. True, there are cases

I agree with your disagreement, but then you're talking about the situations
which XCOPY deployment was designed for :)

Take configuration files as an example. They're great for XCOPY deployment
because they live in the same folder as the app and are identified as such.
However, config files are per-application and if you want to provide
per-user settings you start to run into difficulties. .NET has an admirable
solution for per-user files, its called isolated storage, but these are
stored outside of the app folder, and XCOPY deployment does not work.
is just plain WORKING. The first time I took all of my files in an
ASP.Net application and just dumped them over the old ones, only to
watch everything working flawlessly afterwards, it felt like I just
got the bar;bar;bar on the slot machine!

If it works for you then use it. My goal in life is to find out when things
don't work and point out the problems and how to fix them (if possible).
Thanks for the addition, although I found that in many cases these new
features serve as a burdon on the new .Net programmer, rather than an
advantage. (and then you hear the smart puppy go "I just went into the
wizard and gave all the assemblies in the world full trust", which
kind of defeats the purpose in my mind).

I agree with you and I think that its a wasted opportunity. The stuff I said
about tamperproof assemblies (if you sign them) still holds. But a security
system where users habitually turn off security needs some re-thought.

BTW for other readers - if you cannot get code access security working for
you *do not give assemblies full trust by default*. Please post your
question to microsoft.public.dotnet.security and see if some one can help
you make .NET security work for you. Only the most trusted assemblies should
get full trust.
Let's be honest - if you're a VB6
programmer (who doesn't regularly write in C, C++, Java, etc.), you
simply don't want to hear this "new language" talk while you're
trying to gain some progress in your carreer and move on into the
future.

Possibly, but I thought I would point out to people new to .NET that they
don't have to move to VB.NET by default. Actually VB.NET can do somethings
that C# and C++ cannot do (real, technical things, not just ease of use
things) - and if you need those features then VB.NET is your only choice. In
almost all cases VB6 developers will feel as comfortable with C# as with
VB.NET. You don't have to be scared of curly braces and semicolons ;-)

Richard
 
I

Itai Raz

Possibly, but I thought I would point out to people new to .NET that they
don't have to move to VB.NET by default. Actually VB.NET can do somethings
that C# and C++ cannot do (real, technical things, not just ease of use
things) - and if you need those features then VB.NET is your only choice. In
almost all cases VB6 developers will feel as comfortable with C# as with
VB.NET. You don't have to be scared of curly braces and semicolons ;-)
I totally agree. In fact, I have been through a zig-zag route, when we first
moved some of our VB code to VB.Net (it was only natural to begin with...),
and after a couple of months moved all of the VB.Net code to C# - so that we
can continue with only C# from that point on. I didn't find many advantages
in VB.Net, and those that I found (optional parameters - god damn you C#
team..... It's supported in the framework, why not support it within the
language???????) were not significant enough to justify using it.

--itai
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,734
Messages
2,569,441
Members
44,832
Latest member
GlennSmall

Latest Threads

Top