Pitfalls for converting a .net 2.0 solution to .net 3.5

Question

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 1

I upgraded several projects from Visual Studio 2005 to 2008 with the Wizard, and they all went painless (well... except for that C++ beast. But you're talking about .NET anyway).

Keep in mind that you don't need to upgrade the .NET version. Visual Studio 2008 supports .NET 2.0, 3.0 and 3.5. However, 3.5 is backwards-compatible anyway, since it sits on the same CLR and is, more or less, just some extra libraries. And the "old" libraries stay the same.

I don't know about Entlib.

Why don't you just try and run your unit tests? :)

Answer 2

• Is there any reasons not to let the Visual Studio wizard convert the solution for us?

No.

• Is 3.5 fully backwards compatible with 2.0?

No. There are new features in 3.5 that wouldn't port backwards natively. And (IIRC) there are some deprecations going from 2.0 to 3.5.

• Is Entlib 4.0 fully backwards compatible with 2.0?

I don't think so. 3.5 is listed as a requirement.

Make a backup, run the wizard, see what happens. It might take a while for such a chunky project but you'll be in a position where you can tell if it'll build/run-as-expected.

Answer 3

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

Answer 4

When I upgraded from EntLib 2.0 to 4.0 I observed the following breaking source code change if you use the Caching application block:

• In 2.0, you get a cache manager using CacheManager cache = CacheFactory.GetCacheManager().
• In 4.0, you have to replace CacheManager with ICacheManager or it won't compile.

Also, if you are writing your own exception formatter class for the Exception Handling block:

• In 2.0, you have to define one constructor with the signature (TextWriter, Exception).
• In 4.0, that is obsolete, and you have to define a second constructor with the signature (TextWriter, Exception, Guid).

Answer 5

There aren't supposed to be any breaking changes when migrating from EntLib 3.1 to 4.0:

"There are no breaking changes to the public API. That was one of the design goals of EL4. Just remember EL4 requires .NET3.5.

--Grigori"

http://blogs.msdn.com/agile/archive/2008/05/16/enterprise-library-4-0-for-visual-studio-2008-released.aspx

(Grigori is the Program Manager for EntLib)

I'm not sure about 2.0 to 3.1 though. If I can find the right people @ p&p tomorrow I'll update this.

Ade

Answer 6

Check this link on how to migrate from .net 2.0 to .net 3.5

http://codingreview.blogspot.com/2009/09/how-to-migrate-your-application-from.html