Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > Main Advantages i get when i do a stand alone app in .Net rather than in VB.

Reply
Thread Tools

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

 
 
Punya Narra
Guest
Posts: n/a
 
      02-05-2004
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


 
Reply With Quote
 
 
 
 
Itai Raz
Guest
Posts: n/a
 
      02-08-2004
- .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

"Punya Narra" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> 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
>
>



 
Reply With Quote
 
 
 
 
Richard Grimes [MVP]
Guest
Posts: n/a
 
      02-15-2004
Itai Raz wrote:
> - .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
--
my email http://www.velocityreviews.com/forums/(E-Mail Removed) is encrypted with ROT13 (www.rot13.org)
sign up for my free .NET newsletter at
http://www.wd-mag.com/newsletters/


 
Reply With Quote
 
Itai Raz
Guest
Posts: n/a
 
      02-16-2004
"Richard Grimes [MVP]" <read my sig> wrote in message
news:ODxEp4%(E-Mail Removed)...



> > - .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.


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!

> > - 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.


...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).

> > 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).


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


 
Reply With Quote
 
Richard Grimes [MVP]
Guest
Posts: n/a
 
      02-16-2004
Itai Raz wrote:
> "Richard Grimes [MVP]" <read my sig> wrote in message
> news:ODxEp4%(E-Mail Removed)...
>
>> 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


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
--
my email (E-Mail Removed) is encrypted with ROT13 (www.rot13.org)
sign up for my free .NET newsletter at
http://www.wd-mag.com/newsletters/


 
Reply With Quote
 
Itai Raz
Guest
Posts: n/a
 
      02-17-2004
"Richard Grimes [MVP]" <read my sig> wrote in message
news:(E-Mail Removed)...

> 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


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
run a function as a stand-alone app with arguments shawn bright Ruby 2 12-24-2008 04:28 PM
JVM crashes when calling matlab in stand alone run app. stacey Java 5 12-03-2008 04:07 PM
Where can I get a stand alone version of Macromedia plugins? james Computer Support 1 01-05-2005 10:23 AM
stand alone executable using pp doesn't stand alone Plotinus Perl Misc 2 12-17-2004 01:09 AM
Integrating servlet container into my stand alone App DiscoStu Java 3 09-27-2004 06:05 PM



Advertisments