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

Discussion in 'ASP .Net' started by Punya Narra, Feb 5, 2004.

  1. Punya Narra

    Punya Narra Guest

    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
     
    Punya Narra, Feb 5, 2004
    #1
    1. Advertising

  2. Punya Narra

    Itai Raz Guest

    - .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" <> wrote in message
    news:%...
    > 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
    >
    >
     
    Itai Raz, Feb 8, 2004
    #2
    1. Advertising

  3. 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 is encrypted with ROT13 (www.rot13.org)
    sign up for my free .NET newsletter at
    http://www.wd-mag.com/newsletters/
     
    Richard Grimes [MVP], Feb 15, 2004
    #3
  4. Punya Narra

    Itai Raz Guest

    "Richard Grimes [MVP]" <read my sig> wrote in message
    news:ODxEp4%...



    > > - .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
     
    Itai Raz, Feb 16, 2004
    #4
  5. Itai Raz wrote:
    > "Richard Grimes [MVP]" <read my sig> wrote in message
    > news:ODxEp4%...
    >
    >> 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 is encrypted with ROT13 (www.rot13.org)
    sign up for my free .NET newsletter at
    http://www.wd-mag.com/newsletters/
     
    Richard Grimes [MVP], Feb 16, 2004
    #5
  6. Punya Narra

    Itai Raz Guest

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

    > 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
     
    Itai Raz, Feb 17, 2004
    #6
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. DiscoStu
    Replies:
    3
    Views:
    767
    Bryce
    Sep 27, 2004
  2. V Green
    Replies:
    0
    Views:
    871
    V Green
    Feb 5, 2008
  3. stacey
    Replies:
    5
    Views:
    3,256
    Nigel Wade
    Dec 3, 2008
  4. shawn bright
    Replies:
    2
    Views:
    102
    shawn bright
    Dec 24, 2008
  5. Plotinus
    Replies:
    2
    Views:
    298
    Tad McClellan
    Dec 17, 2004
Loading...

Share This Page