Should upgrade to .NET 2.0 or .NET 3.0?

[Ajith Menon]

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

 

[Andre Kaufmann]

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

 

[Jon Skeet [C# MVP]]

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.

 

[DeveloperX]

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.

 

[Andre Kaufmann]

<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

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

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

 

[Ajith Menon]

| 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