By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,584 Members | 1,803 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,584 IT Pros & Developers. It's quick & easy.

Should upgrade to .NET 2.0 or .NET 3.0?

P: n/a

I am working on a project "ABC" which needs to be upgraded from .NET
framework 1.1.
We are thinking about upgrading it to .NET framework 2.0. The reason
for this is that we have some unmanaged modules (made in VC++) shared
with other project "XYZ". The project "XYZ" is upgraded to .NET
framework 2.0 from .NET framework 1.1.

Now to have the compatibility, forcibly project ABC also have decided
to upgrade to .NET 2.0. But I feel why not directly upgrade to .NET
3.0.

Can anybody tell me in doing this:
1. What advantages do I have in .NET 3.0 over .NET 2.0
(a. project is a windows application,
b. largely using XML files and no SQL databases.
c. It has controls like Tree view and data grids being using
extensively.
d. Lot of interaction with unmanaged code is also expected)

2. Is it error prone if I use an unmanaged code compiled using .NET 2.0
in our project which is going to be in .NET 3.0? If yes what kind of
errors may I have to face?

Regards,
Ajith

Jan 18 '07 #1
Share this Question
Share on Google+
6 Replies


P: n/a
Ajith Menon wrote:
[...]
Now to have the compatibility, forcibly project ABC also have decided
to upgrade to .NET 2.0. But I feel why not directly upgrade to .NET
3.0.

Can anybody tell me in doing this:
1. What advantages do I have in .NET 3.0 over .NET 2.0
Don't bother about .NET 3.0 or .NET 2.0. Basically .NET 3.0 is .NET 2.0
+ former WinFX.

Each .NET 2.0 application will run on .NET 3.0 too.
Though I would recommend you to install .NET 3.0 anyways.
And IIRC some Microsoft employees have stated, that future .NET version
will be downwards compatible and that new functions will only be added,
but no breaking changes will be introduced. So you shouldn't have to
care about downwards compatibility that much in future .NET versions
(hopefully ;-) )
[...]
2. Is it error prone if I use an unmanaged code compiled using .NET 2.0
in our project which is going to be in .NET 3.0? If yes what kind of
errors may I have to face?
Depends. If you are using managed C++ then you'll have to face many
changes. Otherwise, if you are using "only" P/Invoke then you shouldn't
face that much problems. I have only basic experience in ASP.NET so may
statements may not apply to that part of .NET.
Regards,
Ajith

Regards,
Andre
Jan 18 '07 #2

P: n/a
Andre Kaufmann <an*********************@t-online.dewrote:

<snip>
And IIRC some Microsoft employees have stated, that future .NET version
will be downwards compatible and that new functions will only be added,
but no breaking changes will be introduced. So you shouldn't have to
care about downwards compatibility that much in future .NET versions
(hopefully ;-) )
I really hope they didn't say that. Sometimes a change is required to
fix a bug, but that change is effectively a breaking change for people
relying on the previous broken behaviour.

Similarly, things like changing what HashCode returns is a breaking
change: developers shouldn't rely on the values returned being
consistent, but some do.

Being *largely* backward compatible is the best that can be promised,
really, IMO.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Jan 18 '07 #3

P: n/a
I would certainly upgrade to 2.0, although there are some reasons not
to immediately upgrade to framework 3. As mentioned below (above?) 3.0
is an extension of 2.0.

Reasons not to upgrade to 3.0, and these may not affect you but should
be considered. Less 3.0 experience in the marketplace at the moment,
will you need to hire 3.0 developers anytime soon?
Will your customers be willing to roll out 3.0? If it's internal have
you spoken to infrastructure (or what ever team manages that sort of
thing). It gets more complicated if you require it installed on
servers.
Fewer resources such as books based on 3.0.
I've been looking for books on asp.net ajax extensions (previously
Atlas) and the majority don't come out until april/may this year or
later. Ok that's not framework 3 related, but you see my point.

2.0 is a great step up from 1.1 though, I'd encourage everyone to
upgrade.

Ajith Menon wrote:
I am working on a project "ABC" which needs to be upgraded from .NET
framework 1.1.
We are thinking about upgrading it to .NET framework 2.0. The reason
for this is that we have some unmanaged modules (made in VC++) shared
with other project "XYZ". The project "XYZ" is upgraded to .NET
framework 2.0 from .NET framework 1.1.

Now to have the compatibility, forcibly project ABC also have decided
to upgrade to .NET 2.0. But I feel why not directly upgrade to .NET
3.0.

Can anybody tell me in doing this:
1. What advantages do I have in .NET 3.0 over .NET 2.0
(a. project is a windows application,
b. largely using XML files and no SQL databases.
c. It has controls like Tree view and data grids being using
extensively.
d. Lot of interaction with unmanaged code is also expected)

2. Is it error prone if I use an unmanaged code compiled using .NET 2.0
in our project which is going to be in .NET 3.0? If yes what kind of
errors may I have to face?

Regards,
Ajith
Jan 18 '07 #4

P: n/a
Jon Skeet [C# MVP] wrote:
Andre Kaufmann <an*********************@t-online.dewrote:

<snip>
I really hope they didn't say that. Sometimes a change is required to
I haven't found the blog I was referring too, so I can't quote the exact
statement. But they didn't state that they won't change anything, but
won't introduce that many changes as they've done before and will find
other solutions.

For example if you have to break code, you could ship the changed parts
of older version with the newer framework, so that an application using
the old version will still run as expected. But you won't have to
download the complete old framework.
fix a bug, but that change is effectively a breaking change for people
relying on the previous broken behaviour.
Agreed, though most of the .NET 2.0 code should be stable now. Sometimes
changes must be made, though it's better to think it over multiple times
if a change can be prevented.
Similarly, things like changing what HashCode returns is a breaking
change: developers shouldn't rely on the values returned being
consistent, but some do.

Being *largely* backward compatible is the best that can be promised,
really, IMO.
Yes, you can't ensure 100% backwards compatibility. But it's IMHO better
to ship a downwards compatible framework, instead of introducing a
breaking change without thinking it over (and over again)
Andre

Jan 18 '07 #5

P: n/a
Hi,

"Ajith Menon" <ko********@gmail.comwrote in message
news:11**********************@q2g2000cwa.googlegro ups.com...
|
| I am working on a project "ABC" which needs to be upgraded from .NET
| framework 1.1.

Any particular reasons?
| We are thinking about upgrading it to .NET framework 2.0. The reason
| for this is that we have some unmanaged modules (made in VC++) shared
| with other project "XYZ". The project "XYZ" is upgraded to .NET
| framework 2.0 from .NET framework 1.1.

If they are unmanaged, how the are "managed" by 2.0?
If they are unmanaged you can use them from either 1.1 or 2.0 without any
problem

Jan 18 '07 #6

P: n/a

Ignacio Machin ( .NET/ C# MVP ) wrote:
| We are thinking about upgrading it to .NET framework 2.0. The reason
| for this is that we have some unmanaged modules (made in VC++) shared
| with other project "XYZ". The project "XYZ" is upgraded to .NET
| framework 2.0 from .NET framework 1.1.

If they are unmanaged, how the are "managed" by 2.0?
If they are unmanaged you can use them from either 1.1 or 2.0 without any
problem
It is something like ... the unmanaged code which were compiled using
msdev compiler in now getting compiled using .NET 2.0 compiler. But the
code still unmanaged ...!!!
Regards,
Ajith

Jan 19 '07 #7

This discussion thread is closed

Replies have been disabled for this discussion.