Pitfalls for converting a .net 2.0 solution to .net 3.5
We're moving a solution with 20+ projects from .net 2.0 to 3.5 and at the same time moving from Visual Studio 2005 to 2008. We're also at the same time switching from MS Entlib 2.0 to 4.0.
- Is there any reasons not to let the Visual Studio wizard convert the solution for us?
- Is 3.5 fully backwards compatible with 2.0?
- Is Entlib 4.0 fully backwards compatible with 2.0?
Edit: I might been a bit confused when I wrote this, the backwards compatability is supposed to mean; is there anything that exists in a 2.0 project that will not work/compile in 3.5
:)
//W
Answer
We upgrade a rather large solution (20+ projects) from 2005 to 2008 but it was really trivial. Project upgrade only basically. The underlying framework is still the same since both 3.0/3.5 and 2.0 share the same core framework.
As was said above, even though you are upgrading, you don't need to change the framework reference for the projects - in fact, it defaults to leaving the framework at 2.0 instead of changing it to 3.0/3.5. This means you will not be able to take advantage of 3.0/3.5 features until you change the reference (Project Properties page, Application Table "Target Framework" field) but it also means you are that much more assured there won't be additional compatibility issues (as you will get an error adding 3.0/3.5 code until that reference is changed).
New features of TFS 2008 shouldn't be overlooked either though you don't need to upgrade your app to be able to use TFS 2008.
1.1 to 2.0 conversion was much more painful...