What are the advantages of .NET 2.0 over NET 1.1 ?

[Guest]

Hi,

1. I am familiar with .NET 1.1 and not with .NET 2.0 .
if i should start a new networking project should i write it with .net 2.0
beta or
write it with .net 1.1 ?

2. What are the advantages of .NET 2.0 over NET 1.1 that i should consider
when writing a new infrastrcuture networking project ?

Thanks.

 

[Moty Michaely]

Hey Yaron,

There are many many advanteges. First, the VS.NET 2005 has better interface,
..NET framework 2.0 has many new features that enhances the framework 1.1
functionallity. Enhances Security, XML support and much more.
Enhancements in WinForms. And many little things that were missing in .NET
1.1.

Check Microsoft/MSDN for specific information.

 

[Mark Broadbent]

Not entirely sure I agree with you here. I mean is Word 2003 that much
better than Word XP? When do we decide that the pudding is over-egged?
It's a little unfair of me though because I've not spent too much time with
2005 beta 2 YET and a lot with 2003.

A couple of additions to your points.

Team System
Generics (new c# language feature).


Br,

Mark.

 

[Moty Michaely]

Hey Mark,

I havn't considered talking about Team System.

There are many things "Java" like in .NET 2005.

Some things like generic and partial classes that can be very helpful in
Large teams.

..NET 2005 is better, there is no doubt. You can't compare office 2003 and
XP, because office 2003 is not that much better than XP in it's features
than what .NET 2005 is about to be more than 2003.

 

[Bruce Wood]

I haven't worked with VS 2005, but I've seen lots of demos. It's much,
much better than VS 2003. However, I'd hardly consider that as a good
reason to switch. Generics, partial classes, improved data access,
nullable types, ... all of these are far better reasons to switch. My
company will be adopting VS 2005 as soon as we've decided that it's
stable and reliable.

I'm so sure about this because I regularly run across situations in
..NET 1.1 in which I have to do ugly things that would be downright
elegant in .NET 2.0. Mostly this has to do with generics and partial
classes, but the other features would really help me, as well. I can't
wait to adopt .NET 2.0 and rewrite some of the ungainly code I have
underlying my system.

 

[Mark Broadbent]

Hi Moty/ Bruce. Like I said, at present I'm unable to really comment but I
like the fact you two are very positive. For me VS2003 dn 1.1 is a very
strong product. I really hope I'm as happy about the advance in 2005. I've
had the beta2 for a while now but still keep going back to 2003. But will
have to make the full switch soon.

One of my biggest problems about the whole MS .net drive though is really
the way that their IDE's are tied to a particular framework. i.e. VS2002
1.0, VS2003 1.1 and VS2005 2.0. It would be really nice to have seperation
here.
Then it would only be the productivity side that you are loosing out on by
continuing using an old IDE not language additions.
And before anyone says it ....Yes I know I can use the new CSC to compile
2.0 code!

 

[wozza]

I haven't worked with VS 2005, but I've seen lots of demos. It's much,
much better than VS 2003. However, I'd hardly consider that as a good
reason to switch. Generics, partial classes, improved data access,
nullable types, ... all of these are far better reasons to switch. My
company will be adopting VS 2005 as soon as we've decided that it's
stable and reliable.

I'm so sure about this because I regularly run across situations in
.NET 1.1 in which I have to do ugly things that would be downright
elegant in .NET 2.0. Mostly this has to do with generics and partial
classes, but the other features would really help me, as well. I can't
wait to adopt .NET 2.0 and rewrite some of the ungainly code I have
underlying my system.

What's so good about partial classes? Looks like trouble to me.

 

[Jon Skeet [C# MVP]]

What's so good about partial classes? Looks like trouble to me.

It allows you to separate machine-generated parts of some classes from
the customised parts. I don't think it'll be terribly useful very
often, but when it's useful, I think it'll be *very* useful.

 

[Moty Michaely]

You can work simultaneously on the same class!!! it's very powerfull when a
team is working on the same class.

- Moty -

 

[Bruce Wood]

That's an interesting application of the technology. I'd never
considered that. I'd always thought about them the way that Jon
mentioned: the ability to separate machine-generated and hand-generated
parts of the same class. I'm most interested in it for use with
strongly-typed datasets: being able to build them into business objects
by adding your own hand-tooled code without worrying about it being
clobbered if the strongly-typed dataset is regenerated because of a
schema change. It just seemed a nice idea to keep things straight.

Nullable types will be a big plus: the ability to (finally) handle
what's really in the database rather than having to fudge things like
DateTime by using DataTime.MinValue to represent null and such
nonsense.

Generics will be the heavy hitter. I've lost count of the classes I've
written that would be simpler with generics, plus I'd get compile-time
type checking to boot. (I've also lost count of the hours spent
debugging problems that I could have found at compile time if I had
generics to use.)

 

[Jon Skeet [C# MVP]]

Generics will be the heavy hitter. I've lost count of the classes I've
written that would be simpler with generics, plus I'd get compile-time
type checking to boot. (I've also lost count of the hours spent
debugging problems that I could have found at compile time if I had
generics to use.)

While I agree that generics will be lovely to have (especially as it's
been done properly, rather than the kludge which is in Java), what kind
of debugging problems have you had which it would have avoided? I can't
remember *ever* actually putting the wrong kind of thing in an
ArrayList etc, which is the kind of problem which most immediately
comes to mind.

 

[Chad Z. Hower aka Kudzu]

of debugging problems have you had which it would have avoided? I can't
remember *ever* actually putting the wrong kind of thing in an
ArrayList etc, which is the kind of problem which most immediately
comes to mind.

Improper type casts when reading values from them.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Get your ASP.NET in gear with IntraWeb!
http://www.atozed.com/IntraWeb/

 

[Bruce Wood]

Mostly it's been changes to the class hierarchy for already-functioning
code and forgetting to change casts / variable types in some places as
a result. Since the compiler isn't checking, I find out only at run
time, and sometimes well after the fact.

 

[Jon Skeet [C# MVP]]

Improper type casts when reading values from them.

Okay, maybe I should have been more precise: I can't remember ever
casting something from an ArrayList to a type which didn't accurately
reflect the type I put into the list.

In other words, I don't think I've actually ended up with *bugs* due to
lack of generics. I'm not saying it won't be fantastic to have generics
in there for all kinds of reasons - I just don't think it'll prevent
that many bugs, at least for me.

 

[Chad Z. Hower aka Kudzu]

In other words, I don't think I've actually ended up with *bugs* due
to lack of generics. I'm not saying it won't be fantastic to have

You are quite lucky then. I cant remember when Ive made that mistake either - but in my job I do a lot
of code review and consulting for other teams. And its a mistake I see a lot.

Of course I see the C# for flubbed up a lot too, but to discuss that in a C sharp forum brings up
charges of heresy as my article did on it. Sometimes the truth is hard though.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Make your ASP.NET applications run faster
http://www.atozed.com/IntraWeb/

 

[Jon Skeet [C# MVP]]

You are quite lucky then. I cant remember when Ive made that mistake
either - but in my job I do a lot of code review and consulting for
other teams. And its a mistake I see a lot.

Oh dear... in my experience, the way to make sure people get it right
is to make sure they put a comment saying the contents (or the
key/value types for maps) directly above the declaration, making it an
XML doc comment for member variables.

Of course I see the C# for flubbed up a lot too, but to discuss that
in a C sharp forum brings up charges of heresy as my article did on
it. Sometimes the truth is hard though.

And sometimes the truth for one developer isn't the truth for another -
I don't know whether you really don't believe me or not, but I really
can't remember seeing the kind of problem you describe with for loops.
Perhaps it depends on the background of the developers one works with -
most of those I work with have a C-based background...

 

[Chad Z. Hower aka Kudzu]

Oh dear... in my experience, the way to make sure people get it right
is to make sure they put a comment saying the contents (or the
key/value types for maps) directly above the declaration, making it an
XML doc comment for member variables.

Its still a point for bugs to enter, even with a comment. Imagine the type is changed, then you have to go
find all the spots....

And sometimes the truth for one developer isn't the truth for another -
I don't know whether you really don't believe me or not, but I really
can't remember seeing the kind of problem you describe with for loops.
Perhaps it depends on the background of the developers one works with -
most of those I work with have a C-based background...

Yes, but remember that not all C# users have a hard core C background. And its not just VB users, but
other users coming to C# as C# is the "default" language of .NET.

With such developers, its very common. And C programmers will NEVER admit it - but I've seen the
best of C developers do it on ocassion when its not someting simple as 1 to 5. And that one time -
often is a doozy and in more than one case caused a major crash.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Develop ASP.NET applications easier and in less time:
http://www.atozed.com/IntraWeb/

 

[Jon Skeet [C# MVP]]

Its still a point for bugs to enter, even with a comment. Imagine the
type is changed, then you have to go find all the spots....

Sure - it's just never something that's bitten me, I guess.

Yes, but remember that not all C# users have a hard core C
background. And its not just VB users, but other users coming to C#
as C# is the "default" language of .NET.

With such developers, its very common. And C programmers will NEVER
admit it - but I've seen the best of C developers do it on ocassion
when its not someting simple as 1 to 5. And that one time - often is
a doozy and in more than one case caused a major crash.

All I'm saying is that "Sometimes truth is hard" isn't really
appropriate here, because it *isn't* always the truth. I know there was
a smiley there, but before now you've seemed reluctant to accept that
it's just not a bug which hits everyone.

I suspect programmers from every language have off-by-one errors every
so often, whether it's in as the last part of the for loop construct or
not - I just haven't seen it myself at that point.

 

[Chad Z. Hower aka Kudzu]

Sure - it's just never something that's bitten me, I guess.

With a C++ background it wont. Work with students sometime - those new to C++ will make the
mistakes early on. Then they will learn - this is a point I make a lot of mistakes, so I'll pay extra
attention. Then you finally commit to memory and build it in to your workflow natively and never
do it again. But in teaching students, Ive never seen them goof up a VB style one.

All I'm saying is that "Sometimes truth is hard" isn't really
appropriate here, because it *isn't* always the truth. I know there
was a smiley there, but before now you've seemed reluctant to accept
that it's just not a bug which hits everyone.

I never said it hits everyone. I said that its a roach point for many developers. But those with C++
background seem to think that since they dont make the mistake - that it must not be common with
others.



--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Empower ASP.NET with IntraWeb
http://www.atozed.com/IntraWeb/

 

[Jon Skeet [C# MVP]]

With a C++ background it wont.

Well, C/Java background.

Work with students sometime - those new to C++ will make the mistakes
early on. Then they will learn - this is a point I make a lot of
mistakes, so I'll pay extra attention. Then you finally commit to
memory and build it in to your workflow natively and never do it
again. But in teaching students, Ive never seen them goof up a VB
style one.

I think I'll take the more expressive form which takes a tiny bit

I never said it hits everyone. I said that its a roach point for many
developers. But those with C++ background seem to think that since
they dont make the mistake - that it must not be common with others.

Well, you've given the impression in the past that you see this
happening all the time. I've worked with a fair number of people and
hardly ever seen it. It's not a case of me not admitting anything, as
your "sometimes truth is hard" implies (albeit not with reference to me
at the time), it's a case of what you see as a common error being
something I genuinely see as a rare one.

Put it this way - for every time I see a for loop with the wrong end
point, I probably see dozens of failures to use a "using" block to
dispose of a resource, or failures to check the return value of
Stream.Read, or assumptions that characters are always ASCII, or
literal insertion of user data into SQL statements. *These* are what I
would call "roaches" rather than for loops. Heck, if people really want
to code for loops with inclusive end points, it's not hard to write:

for (int i=0; i <= 4; i++)
{
}

instead of

for (int i=0; i < 5; i++)
{
}

I would get very worried if I saw any member of my team making that
kind of mistake on anything more than a "once in a blue moon" basis.