Migration to .NET 3.5 Framework

 

In this article, we discuss issues concerning migrating .NET codebase to a .NET 3.5 framework (from .NET 2.0), as far as development and production environment is concerned. It contains in fact excerpts from the most important articles, arranged in as logical as possibal way.

General Overview

Using NDepend, you can see a summary statistics for .NET 3.5 changes. More in detail, you can read about these changes at  codebetter.com.. Or a simple list can be found at the blog of   Scott Hanselamn. If you want to detect framework version, read this msdn tip. You can also check wikipedia.

An interessting blog about how the .net versions relate to each other can be found at Dr Z’s blog.


Green bits and red bits

As you can read at  Daniel Moth’s blog  or  Somasegar’s Weblog or Jason Zander’s Weblog, Fx 3.5 includes v2.0 SP1 and v3.0 SP1 – those are the red bits, in other words the only changes, which come together with .NET 3.5 installation (if you don’t have these service packs). Like with all service packs, there should be nothing in there that could break your application. Having said that, if a bug is fixed in the SP and your code was taking advantage of that bug, then your code will break of course. To be absolutely clear, this is an in-place upgrade to v2 and v3, not a side-by-side story at the framework/clr level. Green bits are those assemblies added in .NET 3.5 – these cannot break your code at all.

 

The .NET Framework assemblies are loaded from the GAC at runtime by the CLR. The non-GAC versions are used by VisualStudio to reference .NET Framework assemblies from your VisualStudio project. VisualStudio doesn’t deal with the GAC.


What is really new

Possible Problems

In this Stackoverflow  discussion, you will find:

  • If you start using types in SP1 even in what you think is 2.0, it will fail on a “proper” 2.0 client.
  • There are (in the service pack) changes to things deep in the core – the number of pool threads, for example (or is it the stack size of pool threads… something in that area) that can bite you if you are unlucky.

Breaking Changes

ASP.NET

Converting the website to 3.5 mostly affects the web.config.

  • Some references are added to a few default 3.5 assemblies, such as System.Core.dll.
  • Changes regarding AJAX: new version of System.Web.Extensions
  • And it will add the IIS 7 sections (which is all ignored if the site is published to an IIS6 box). See more at Stackoverflow. Or read about web.config files by 4guysfromrolla.

How to set an IIS Application or AppPool to use ASP.NET 3.5 rather than 2.0, is described by  Scott Hanselman. Another article is here by Vijayshinva Karnure.

NetFX 3.5 SP1

What is new is described at msdn. As you can find at the download page, Microsoft .NET Framework 3.5 Service Pack 1 is a full cumulative update that contains many new features building incrementally upon .NET Framework 2.0, 3.0, 3.5, and includes cumulative servicing updates to the .NET Framework 2.0 and .NET Framework 3.0 subcomponents. It means, no breaking changes. The same can be found here: The updates include non-breaking changes, new API elements, and additional functionality for the technologies that were included in the .NET Framework 3.5.

NetFX 4.0

Tooling

You can use FxCop to detect possible problems, as you can read here (Krzysztof Cwalina), at Dave’s Box or at Stackoverflow.
 

Should I change Target Framework of my visual studio projects?

Most developers think you should do it, because this looks like explicit migrating of your projects to .NET 3.5. However, the only thing which is changes in your csproj file, if you change Target Framework in properties of your project, is this:
 
It means, it references a totaly new assembly System.Core.dll, which contains new features of .NET 3.5 – as you can read e.g. here (Daniel Moth), it belongs to the green bits (see above). It is really transparent, as you can see e.g. in the blog of Scott Hanselman. It further means, that if you just change the setting and don’t use anything from System.Core.dll, the reference to System.Core is in fact not included into your assembly – in other words, nothing changes in runtime just by changing Framework Target.
 
In my opinion, it has no sense to change Target Framework for all projects, if you don’t use features of .NET 3.5. It is even confusing, as you don’t know anymore, which assemblies you can use on .NET Framework 2.0. However I can understand, that some purists will consist on doing this change explicitly.
 

3rd-party assemblies

We know only about these possible problems:
- Rhino.Mocks – as you can read in the Ayende’s blog, Rhino.Mocks can have problem with .NET 3.5 SP1. However, firstly we have not experienced this problem (all unit tests have passed), secondly there is a Microsoft fix and the problem applies only to these systems:
Win2000, WinXP, WinServer 2003.
 

Summary

If we already use .NET2.0 SP2, installing .NET3.5 brings only new “green bits“, which cannot make any problems to the existing code base.
August 8th, 2009 in .NET, English | tags: , , ,

Leave a comment

Your comment