views:

107

answers:

4

is there any documentation on changes that i might hit when migrating an app from dotnet 2.0 to 3.5. Its my understanding that this is not really a core runtime change but rather an addition of a bunch of new libraries (LINQ, etc). Assuming i am correct, should I have to change any 2.0 code at all to compile successfully in 3.5. My of a concern than compile time breaks is anything that compiles fine but subtlely work different.

+7  A: 

.NET 3.5 adds a lot of new assemblies, but the core runtime is still 2.0. Or actually it is 2.0 SP1, so in very rare cases you may see differences, but in most cases you shouldn't have to do anything.

There's a useful overview of the versions on wikipedia.

Brian Rasmussen
A: 

The simple answer is that switching the targeted runtime of the application shouldn't cause broken functionality.

STW
+1  A: 

The run time is actually the same for the libraries which you would currently be using. When we moved, we didn't have any issues. There was a service pack 1 change to 3.5 that could cause some SQL CE issues, but I'm not aware of anything else.

Jim Leonardo
A: 

You have to be aware of the fact that when you install 3.5, the installation will also include servicepacks on the 2.0 version. These 2.0 servicepacks do have for instance new methods implemented that do not exist on the core 2.0 version.
The situation you might get into would be that you'd develop a 2.0 functionality on a 3.5 installation and would expect to run it without problems on a machine that has only 2.0 installed, which will give you something like a MethodMissingException as a result because that older system might not have the new method or property.

Mez
i dont understand your answer. all machines would have 2.0 and 3.5 side by side
ooo