Book for VB .NET newbie/novice

[jy836]

I am an amateur programmer (it's more of a hobby for me, actually). Years
ago, I used VB 3 for a year or two, and then just forgot about programming
for quite some time. About a year ago, I started to look into it again, and
realized that obviously VB 3 was not up to par with modern software
development. So I purchased VS .NET 2003, and though many of the same
keywords and principles carry over from VB to VB.NET, there are many things
I don't understand. This is partly because I never really got into a
programming book; I taught myself for the most part.

Because of this, there were quite a few fundamentals I was unclear on, and
VB .NET simply introduces even more foreign concepts. I've been hesitant,
however, to get a Beginner's Guide to VB .NET, because I do understand how
to create forms, add controls, have code execute when events take place,
access files (though again, I do that with the FileOpen function, because
that is closer to the old VB style that I am used to), etc. So it's not like
I have no concept of how to use the language.

I'm simply wondering what the best comprehensive book would be for someone
in my situation, that wants to learn the fundamentals. I feel like I've
skipped past some of them and only learned what I needed to for specific
applications. Along the way, I've probably missed a lot. I want to
completely understand such things as classes, inheritance, overloading,
overriding, owner-drawn controls (I literally have almost no idea what that
refers to), etc.

Any recommendations? (This can even include online tutorials or books.)

 

[jy836]

I am an amateur programmer (it's more of a hobby for me, actually). Years
ago, I used VB 3 for a year or two, and then just forgot about programming
for quite some time. About a year ago, I started to look into it again, and
realized that obviously VB 3 was not up to par with modern software
development. So I purchased VS .NET 2003, and though many of the same
keywords and principles carry over from VB to VB.NET, there are many things
I don't understand. This is partly because I never really got into a
programming book; I taught myself for the most part.

Because of this, there were quite a few fundamentals I was unclear on, and
VB .NET simply introduces even more foreign concepts. I've been hesitant,
however, to get a Beginner's Guide to VB .NET, because I do understand how
to create forms, add controls, have code execute when events take place,
access files (though again, I do that with the FileOpen function, because
that is closer to the old VB style that I am used to), etc. So it's not
like I have no concept of how to use the language.

I'm simply wondering what the best comprehensive book would be for someone
in my situation, that wants to learn the fundamentals. I feel like I've
skipped past some of them and only learned what I needed to for specific
applications. Along the way, I've probably missed a lot. I want to
completely understand such things as classes, inheritance, overloading,
overriding, owner-drawn controls (I literally have almost no idea what
that refers to), etc.

Any recommendations? (This can even include online tutorials or books.)

Also, another couple questions (totally unrelated, but I didn't want to
start another thread): Will there be an Academic edition of VS. NET 2005?
When will the VS .NET 2005 family be out? Thanks in advance.

 

[dinny]

VB .NET is as complicated as C++. Be prepared for a few semesters
of hard work. One source of information is msdn.microsoft.com,
though the VB6 Programmer's Guide was much more step by step
sort of thing, i.e very methodical. I am not sure the VB7 walkthroughs,
as they are called now, give you all that you need, maybe someone
will comment as well.

 

[dinny]

Just start from the ground up/learn about the dotNet fundamentals re:the
CLR

is CLR really important? I am quite good with VB.NET and I am not sure
what CLR is actually?! I do know that I can decompile programs with
ildasm, is that what you mean by CLR?

 

[Scott M.]

I disagree. VB.NET is not nearly as complicated as C++. And, VB.NET is not
generally referred to as VB7.

 

[Scott M.]

LOL!! Yes, the CLR is the most critical part of the .NET Framework.

No offense, but if you don't have much knowledge about the Framework and the
CLR in particular, then you can't be that good at VB.NET. You may know the
syntax well, but you have no idea of how your code is being managed, which
means you are probably not writing very efficient code.

The CLR (Common Language Runtime) is the engine that is responsible for
actually processing any code written in any .NET language. Within the CLR,
there are several sub-components to handle specific tasks (such as
language-specific compilers, garbage collection, the Common Type System,
etc.). This is where your VB .NET code ultimately runs from.

ILDASM.exe is just a program used to look at the Intermediate Language (IL)
code of an assembly. IL is the in between state that your code exists in
after VS.NET gets done with it but before the CLR gets its hands on it.

Understanding the CLR means understanding the Common Language Specification
of .NET, understanding what Garbage Collection is and how it works (HUGELY
IMPORTANT TO WRITING EFFICIENT CODE), understanding how exceptions affect
overall performance, etc.

Here's an example of how knowing VB.NET, but not knowing what the CLR is or
what it does is a bad thing:

You'll run into classes that have Dispose and Finalize methods and you have
the ability to add these methods to your own classes as well. If you don't
know what Garbage Collection is or how it works, you will most certainly use
these methods incorrectly or (perhaps worse) not use them at all because you
don't know what they do.

Trust me, as good as you think you are, you are working with one hand tied
behind your back.

 

[Scott M.]

I would suggest you not try to take a shortcut and skip over the things that
you learned from VB3. While it is true that some syntax has remained the
same, what is happening under the hood is entirely different.

Given how long ago it was that you used VB and how many versions ago it was
as well, I'd say come at VB.NET as if you had never used VB before and don't
skip over anything. You are sure to find very simple things that may look
the same as you remember them, but work very differently now.

I like Francesco Balena's MS Press book: Programming Visual Basic.NET (for
VS.NET 2003 & 1.1 Framework)
http://www.amazon.com/exec/obidos/tg/detail/-/0735620598/002-4317085-2940864?v=glance

 

[Ged Mead]

I've been hesitant,
however, to get a Beginner's Guide to VB .NET, because I do understand how
to create forms, add controls, have code execute when events take place,
access files (though again, I do that with the FileOpen function, because
that is closer to the old VB style that I am used to), etc. So it's not like
I have no concept of how to use the language.

Any recommendations? (This can even include online tutorials or books.)

If you feel reasonably confident of your ability to build on your
Classic VB knowledge, then the Francesco Balena book recommended earlier is
an excellent reference source.

Another MS Press book which assumes previous VB knowledge (but which
includes clear descriptions of those areas that many Classic VB-ers may have
skipped over, such as Classes and OOP) is "Coding Techniques for Visual
Basic.Net " By John Connell. Very clearly written.

I also found "Mastering VB.Net by E. Petroutsos (Sybex) very useful in
the early days of the VB.Net learning curve. Although this book doesn't
assume previous VB knowledge, it did help that I actually had a track record
in VB6.

Apart from books, there are so many on line resources that it's hard to
know where to begin. Without doubt, my personal favourite is
www.vbcity.com , a site which has lively and helpful forums on all things
VB, plus a hefty FAQs section and many articles for VB.Net Newbies. Oh,
and an email newsletter too, which always contains VB.Net articles at
various knowledge levels.

 

[Ged Mead]

I've been hesitant,

however, to get a Beginner's Guide to VB .NET, because I do understand how
to create forms, add controls, have code execute when events take place,
access files (though again, I do that with the FileOpen function, because
that is closer to the old VB style that I am used to), etc. So it's not like
I have no concept of how to use the language.

Any recommendations? (This can even include online tutorials or books.)

If you feel reasonably confident of your ability to build on your
Classic VB knowledge, then the Francesco Balena book recommended earlier is
an excellent reference source.

Another MS Press book which assumes previous VB knowledge (but which
includes clear descriptions of those areas that many Classic VB-ers may have
skipped over, such as Classes and OOP) is "Coding Techniques for Visual
Basic.Net " By John Connell. Very clearly written.

I also found "Mastering VB.Net by E. Petroutsos (Sybex) very useful in
the early days of the VB.Net learning curve. Although this book doesn't
assume previous VB knowledge, it did help that I actually had a track record
in VB6.

Apart from books, there are so many on line resources that it's hard to
know where to begin. Without doubt, my personal favourite is
www.vbcity.com , a site which has lively and helpful forums on all things
VB, plus a hefty FAQs section and many articles for VB.Net Newbies. Oh,
and an email newsletter too, which always contains VB.Net articles at
various knowledge levels.

 

[Herfried K. Wagner [MVP]]

LOL!! Yes, the CLR is the most critical part of the
.NET Framework.

I agree that it is one of the important parts of the .NET Framework, but
it's not a part of VB.NET and thus not as important for VB.NET. I consider
the CLR an "implementation detail" which you should not need to care about
too much. The CLR is like an engine of a car -- do you really need in-depth
knowledge about the certain type of engine in your car in order to be able
to drive it? No. You need to know that it's the engine, that's all.

No offense, but if you don't have much knowledge about the
Framework and the CLR in particular, then you can't be that
good at VB.NET.

I disagree. Up to a certain point knowledge about the GC is important to
understand runtime characterstics of applications written in VB.NET, but
it's completely unimportant to know that MSIL exists and that there is a JIT
compiler. That's something the developer (the user of the "tool" VB.NET)
should not need to worry about.

You may know the syntax well, but you have no idea of how
your code is being managed, which means you are probably not
writing very efficient code.

Writing "efficient" code requires far more knowledge in algorithm design and
implementation than knowledge about the CLR, IMO. Sure, you can do some
optimizations if you know a lot about the CLR, but I doubt that all these
optimizations will raise the value of your code.

Here's an example of how knowing VB.NET, but not knowing what the CLR is or
what it does is a bad thing:

[GC example]

Yep, that's a valid reason to know something about GC, because it has a big
impact on your application.

 

[dinny]

I disagree. VB.NET is not nearly as complicated as C++. And, VB.NET is
not

generally referred to as VB7.

If you look where your visual studio is installed, you will see vb7, vc7.
I too have noticed people don't refer to it as that, but this is what it
is. It probably depends who you ask. If you ask a Microsoft marketing
person, he will tell you vb.net. If you ask a Microsoft systems programmer
he may tell you vb7. IMHO it is better to call it vb7, because vb6 was
a really good product, and you want to build on its success rather than
disassociate yourself from it, and secondly, people like continuation and
dislike changes. It is like those people in the big stores who change the
position of their products all the time. They think it's good for business,
but it's not. People will remain more loyal to the one who doesn't
constantly tell them "what was in the past was bad. Our new arrangement
is better/more cool.

 

[jy836]

I am an amateur programmer (it's more of a hobby for me, actually). Years
ago, I used VB 3 for a year or two, and then just forgot about programming
for quite some time. About a year ago, I started to look into it again, and
realized that obviously VB 3 was not up to par with modern software
development. So I purchased VS .NET 2003, and though many of the same
keywords and principles carry over from VB to VB.NET, there are many things
I don't understand. This is partly because I never really got into a
programming book; I taught myself for the most part.

Because of this, there were quite a few fundamentals I was unclear on, and
VB .NET simply introduces even more foreign concepts. I've been hesitant,
however, to get a Beginner's Guide to VB .NET, because I do understand how
to create forms, add controls, have code execute when events take place,
access files (though again, I do that with the FileOpen function, because
that is closer to the old VB style that I am used to), etc. So it's not
like I have no concept of how to use the language.

I'm simply wondering what the best comprehensive book would be for someone
in my situation, that wants to learn the fundamentals. I feel like I've
skipped past some of them and only learned what I needed to for specific
applications. Along the way, I've probably missed a lot. I want to
completely understand such things as classes, inheritance, overloading,
overriding, owner-drawn controls (I literally have almost no idea what
that refers to), etc.

Any recommendations? (This can even include online tutorials or books.)

Thanks to all for your responses.

 

[Scott M.]

I agree that it is one of the important parts of the .NET Framework, but

it's not a part of VB.NET and thus not as important for VB.NET. I
consider
the CLR an "implementation detail" which you should not need to care about
too much. The CLR is like an engine of a car -- do you really need
in-depth
knowledge about the certain type of engine in your car in order to be able
to drive it? No. You need to know that it's the engine, that's all.

With this statement, you have made my point. You don't need to know about a
car's engine in order to drive it, but if you wish to drive it to the best
of its abilities, then, YES, you do need to know about its engine. Ask any
professional car driver about his/her egine and they will tell you anything
you want to know.

I disagree. Up to a certain point knowledge about the GC is important to
understand runtime characterstics of applications written in VB.NET, but
it's completely unimportant to know that MSIL exists and that there is a
JIT
compiler. That's something the developer (the user of the "tool" VB.NET)
should not need to worry about.

Again, you don't *need* to know it and you can write code that works. But
to write efficient code you do need to know it. Why does every book on
VB.NET start out by talking about the .NET Framework and the CLR?

Writing "efficient" code requires far more knowledge in algorithm design
and
implementation than knowledge about the CLR, IMO. Sure, you can do some
optimizations if you know a lot about the CLR, but I doubt that all these
optimizations will raise the value of your code.

You can write a wonderful algorithm, but if you don't understand what boxing
is, how can your ensure that you are writing an efficient algorithm?

Here's an example of how knowing VB.NET, but not knowing what the CLR is or
what it does is a bad thing:

[GC example]

Yep, that's a valid reason to know something about GC, because it has a
big
impact on your application.

The example I gave was just one of many that show that what you write in
VB.NET can and is greatly affected by the CLR. When MS created .NET, they
did something very different from Java. They created the Framework first
and then .NET languages second. The idea was that the CLR (and the rest of
the Framework components) would be where the real work gets done and the
language would just be an interface to the CLR. To ignore the CLR and just
focus on the language is, as I said before, "working with one hand tied
behind your back" or perhaps more correctly "working with one eye closed".

 

[Scott M.]

I never said that VB .NET wasn't internally referenced as VB7, what I said
was that VB.NET is not generally referred to as VB7 and that is not an
opinion, it is a fact. Just as Word 2003 is actually Word v11.61x, it is
referred to as Word 2003. I made this point to try to help *you* as you
discuss with others VB.NET.

The reason MS pushed the ".NET" name is VS.NET and VB.NET was to try to
clearly tell the public that these versions of the software were something
very new and different from their processors. As we have now had nearly 3
years of these products being in the main stream, MS will go back to just VS
and perhaps VB (as with Visual Studio 2005, not Visual Studio.NET 2005).

Go to any bookstore and find a book on VB.NET entitled VB 7.0, rather than
VB.NET. Do an Amazon.com search on "Visual Basic 7.0". All you will come
up with are books on VB.NET (or even VB.NET 2002).

You are certainly entitled to call it anything you want, but to avoid
confusion (especially here in NG's with many newbies), it is probably best
not to use terminology that is not what is generally used.

 

[Scott M.]

To address these points specifically:

IMHO it is better to call it vb7, because vb6 was
a really good product, and you want to build on its success rather than
disassociate yourself from it, and secondly, people like continuation and
dislike changes.

VB 6.0 was a wonderfully popular product, but many of us have known for
years that VB 6.0 was not necessarially a really "good" product when it came
to OO features and the ability to control all aspects of what the code was
doing.

As I state in my other reply, the name change was done exactly for the
reason you state above: to (partially) dissasociate VB.NET from VB 6.0 and
to (partially) indicate that this is NOT just an upgrade to VB 6.0. It is,
in fact, a change.

 

[Richard Myers]

IMHO it is better to call it vb7, because vb6 was

a really good product, and you want to build on its success rather than
disassociate yourself from it,

Yes but vb6 was an entirely different product. It had a different runtime
(these days we have the CLR), it used a different development methodology,
it wasn;t JIT compiled;blah blah blah. This is a bit like saying the new
Fords should be called Model T 1200's. VB6 was also a standalone product.
..NET products are part of a product/server group. C# .NET / ASP.NET / ADO
..NET etc etc. This ["success rather than disassociate yourself from it"] is
precisely the reason why you WOULD call it dotNet... so as too associate all
the new technologies under a single banner.

and secondly, people like continuation and

dislike changes.

Well then they shouldnt be in the technology industry where change is a
given. Beyond that i think the last 15 years disprove this point beyind a
doubt. Who had a cellphone and an Ipod 15 years ago? People love change and
innovation.

It is like those people in the big stores who change the

position of their products all the time. They think it's good for business,
but it's not.

Clearly it must be good for business and these people must know what they
are doing if they are so big. You dont grow by doing the wrong things.

 

[dinny]

bla bla bla

 

[Richard Myers]

I agree with Scott.
Nobodies talking about a completely thorough understanding of the CLR at the
level of say a K

Dinny was saying he used ILDASM but didn't know what the CLR is?
If you dont know what the CLR is then how can you rationalise what your
looking at through ILDASM?

Whatever algorithm we produce will ultimately be packaged as an assembly of
the dotNet framework.
If you dont know what the CLR is then you wont know theres a 20MB download
on top of your application size if you wish to distribute via the internet.

If its possible to get by with zero knowledge of the CLR then why cant we
deploy to the Linux framework? And given two precisely coded algorithms one
coded in VB.NET the other in C++, why do those in the C++ camp claim theirs
would be more performant? Why does this performance gap reduce after the
first execution of the VB.NET version and why do some us of make good use of
NGen.exe.

If you dont know that basics of the CLR, or more importantly dismiss
knowledge of the CLR as unimportant, (because a willingness to learn is just
as important as having the learning) then one can never be any good and
certainly not a professional developer on the dotNet framework.

We know your a highly competent developer Herfried. I wonder if you simply
take for granted how many design/performance decisions you make into which
you have implicitly factored your knowledge of the CLR and its place in the
framework. Its a little bit like when we fill up our cars at the petrol
pump. If your like me you spend most of the time bemoaning the high price of
fuel and although I dont explicitly think about my engine in terms of
pistons/compression/cambelts/torque/rpms etc, i generally check the oil and
i never put diesel into my super premium grunt machine.

I knew before i bought my first car why i had to do these things because i
understood that the engine is the most important component in my car. It
doesn;t matter how good the paint work is nor how expensive the mags, Im not
going to get alot of joy using a 2 cyclinder engine in an off road mud trap.
I know this because i understand the basics re:engines .... i.e the CLR.

And beyond this rant, i dont think anyones even mentioned the role of the
CLR in terms of application security? How can anyone possibly build a secure
application without a decent understanding of the CLR, let alone without
even knowing what it actually is?

Richard

I agree that it is one of the important parts of the .NET Framework, but
it's not a part of VB.NET and thus not as important for VB.NET. I
consider
the CLR an "implementation detail" which you should not need to care about
too much. The CLR is like an engine of a car -- do you really need
in-depth
knowledge about the certain type of engine in your car in order to be able
to drive it? No. You need to know that it's the engine, that's all.

With this statement, you have made my point. You don't need to know about a
car's engine in order to drive it, but if you wish to drive it to the best
of its abilities, then, YES, you do need to know about its engine. Ask any
professional car driver about his/her egine and they will tell you anything
you want to know.

I disagree. Up to a certain point knowledge about the GC is important to
understand runtime characterstics of applications written in VB.NET, but
it's completely unimportant to know that MSIL exists and that there is a
JIT
compiler. That's something the developer (the user of the "tool" VB.NET)
should not need to worry about.

Again, you don't *need* to know it and you can write code that works. But
to write efficient code you do need to know it. Why does every book on
VB.NET start out by talking about the .NET Framework and the CLR?

Writing "efficient" code requires far more knowledge in algorithm design
and
implementation than knowledge about the CLR, IMO. Sure, you can do some
optimizations if you know a lot about the CLR, but I doubt that all these
optimizations will raise the value of your code.

You can write a wonderful algorithm, but if you don't understand what boxing
is, how can your ensure that you are writing an efficient algorithm?

Here's an example of how knowing VB.NET, but not knowing what the CLR

is
or

what it does is a bad thing:

[GC example]

Yep, that's a valid reason to know something about GC, because it has a
big
impact on your application.

The example I gave was just one of many that show that what you write in
VB.NET can and is greatly affected by the CLR. When MS created .NET, they
did something very different from Java. They created the Framework first
and then .NET languages second. The idea was that the CLR (and the rest of
the Framework components) would be where the real work gets done and the
language would just be an interface to the CLR. To ignore the CLR and just
focus on the language is, as I said before, "working with one hand tied
behind your back" or perhaps more correctly "working with one eye closed".

 

[Richard Myers]

I think i may have meant to say a "Jim Millar" or a " Jim Hogg" in my
previous post.

 

[Richard Myers]

"dinny" > bla bla bla

aka Inarticulate.