Are There Any .NET Framework 3.5 Rollout Cautions?

Question

What level of concern should I attach to deploying the .NET framework 3.5 onto a production application server currently hosting about 20 .NET framework 2.0 applicatons?

I have a run into resistance to my request to rollout the .NET framework 3.5 into our environment. We do not have the ability to regression test with confidence nor do we have available resources to test each application with confidence.

It is my understanding that the .NET framework X.X is, as a primary design objective, constructed and proven to allow 1.0, 1.2, 2, 3, 3.5 etc.. to be deployed on the same machine with with high confidence that the interplay between the versions will not break eairlier version.

I have tried to find 'breaking changes' that are reported in the IT community and thus far have found very very few examples and as such I am inclined to press for the rollout of this runtime with minimal testing.

What is your preceived level of concern about this approach to rolling out .NET 3.5 in this situation.

Answer 1

My level of concern is very low. The only way in which the 3.5 framework will interact with existing 2.0 applications is due to the service pack applied to the 2.0 CLR during the 3.5 install. Namely service pack1. So after the install all of your previous apps will start running on CLR 2.0SP1 vs. CLR 2.0.

So really this is a question of how much confidence do you have in the service pack?

Here is a link to the service pack and the list of bugs they fixed. All bug fixes are in a way a breaking change and can affect application behavior (otherwise why fix it?).

• http://support.microsoft.com/kb/945757

Answer 2

.Net 2.0 is really just a subset of .Net 3.5

Both of these are built on top of the CLR 2.0

3.0 Added the Foundation libraries (WF, WCF, WPF), and 3.5 was another rollout of additional features. All in all, you should have absolutely no problems whatsoever unless you have done something completely crazy on your machines.

Answer 3

I understand your concern, and would usually recommend doing as much testing as you can on a server in a non-production environment first.

But - having said that, the core runtime components of .NET 3.5 are the same as those in .NET 2.0. Version 3.5 is essentially .NET v2.0 with extra libraries on top.

As you say - the frameworks are designed to co-exist quite hapily, so it should all be ok.

We certainly didn't have any problems rolling out in our live environment.

Disclaimer: All of the above is just from my experience - please don't blame me if it all goes wrong! ;o)

Answer 4

Multiple dotnet versions can reside on a same machine and a dot net assembly is actually hold its target framework in its manifest. Hence if an application is compiled with 2.0 or older and you have that version exists on your machine then there is absolutely no problem. This is what dotnet frame have targeted in first place. Side by side execution and elimination of DLL hell problem.

However upward compatibility was never bin an issue... if an assembly is compiled with version 2.0 it'll run perfectly in later versions... However if some thing still goes wrong you need to blame MS :P..

In case of new versions, luckily we are mature enough to only enforce the deprecated check during compile time. In execution it'll have no issues.

About those error conditions which comes out after new functionality addition in frame work (As you mention regression testing your application)... well there is always a chance though its a very rare one. However if you are going towards side by side dotnet framework execution option then the assembly will be loaded and run in its targeted framework if exists on the machine.

Answer 5

While I agree with everyone here, I would add one comment. If you're installing .NET 3.5 with Service Pack 1, you do get some extra permissions pushed into the machines automatically that allow .NET code on network shares to run with full permissions, the same as if they were running on the local hard drive. If that's an issue for you, then you may want to look at restricting the permissions.