Why Should I Upgrade from .Net Framework 3.5 to .Net Framework 4 ? (Navneet Gupta)

I was chatting with some of my friends about Visual Studio 2010 and .Net Framework 4 and they asked me why should they move their application to .Net Framework 4, I am answering the question here for everybody to benefit. Frankly speaking there is no definitive answer; it is like there is no single pill that can cure all the problems. It all depends upon the application features and customer scenario.

Here is the summary of major advantages of targeting .Net Framework 4 and other reasons why you may decide to stick to .Net Framework 3.5 for time being. I am writing this post keeping in mind the VSTO developers but most of this applies to any managed application.

.Net Framework 4 comes with lots of cool features and many of them were developed keeping an Office developer in mind. Check out this article for all the new features in .Net Framework 4.

Here is the list which I feel will interest the Office developers the most.

Deploying pre-requisites for Office customizations have been a major pain point for many VSTO developers. Two new features in .Net Framework 4 address deployment of pre-requisites very well.

Size of .Net Framework

The size of the .Net Framework redistributable is greatly reduced, the table below summarizes the difference between .Net Framework 3.5 SP1 and .Net Framework 4.


3.5 SP1

4.0 RTM

32 bit Client Profile

Online: 28 MB
Offline: 255MB

28.8 MB

32 + 64 bit Client Profile


41 MB

32 bit Full


35.3 MB

32 + 64 bit Full


48.1 MB

32 + ia64 bit Full


51.7 MB

32 + 64 + ia64 bit Full

231 MB


Here is the above data in chart format. 


As it is very clear from above table and chart that the size is greatly reduced for the redistributables. The web installers for .Net Framework 4 are under 1 MB in size (they require active internet connection to download the bits).

This is great enhancement; almost all Office applications will only require .Net Framework 4 Client profile. This article explains .Net Framework 4 Client profile. This blog shads more light on .Net Framework 4 Client Profile.

The .NET Framework 4 Client Profile does not include the following features. You must install the .NET Framework 4 to use these features in your application:


· Advanced Windows Communication Foundation (WCF) functionality

· .NET Framework Data Provider for Oracle

· MSBuild for compiling

Type Embedding and Type Equivalence

Another major concern related to deployment of Office customizations was deployment of Primary Interop Assemblies (PIAs). Before .NET Framework 4 if the customization only used some of the interfaces and methods from the Interop Assemblies, the complete set of the Primary Interop Assemblies still had to be deployed. .Net Framework 4 addresses this in very elegant way. The C# and VB compilers provide a /link switch that embeds the types referenced from the Primary Interop Assemblies into the application assembly itself. , Type Equivalence in the CLR can understand these embedded types and link them to the appropriate types at runtime. With this the customization does not require deployment of the Primary Interop Assemblies on end-user computers.

For more information about Type Embedding and Type Equivalence refer these blog posts.

The Pain of deploying Primary Interop Assemblies

Walkthrough: Embedding Type Information from Microsoft Office Assemblies (C# and Visual Basic)

VSTO Runtime Improvements

There have been some major improvements in VSTO Runtime 4.0 for the customizations that target .Net Framework 4. These enhancements were possible because of Type Embedding and Type Equivalence features of the compilers and CLR.

At a high level the VSTO Runtime has three major components; Unmanaged Components, Office Runtime 3.5 Extensions and Office Runtime 4.0 Extensions. Office Runtime 3.5 Extensions are used by the Office customizations that target .Net Framework 3.5 and Office Runtime 4.0 Extensions are used by the Office Customizations that target .Net Framework 4. This blog post explains the runtime extensions in detail.

The Office runtime 3.5 Extensions use the Managed AddIn Framework (MAF) to load the customization and to establish a communication link between the host application and the customization. MAF provides lots of benefits in terms of flexibility and version control, but it comes with some performance bottlenecks and implementation related design issues because of long chain of assemblies in MAF Pipeline.

Office runtime 4.0 extensions were developed using Type Embedding and Type Equivalence and we do not require MAF anymore, this improves customization loading time and our ability to provide future enhancements to the runtime at much lower cost. This blog post explains the design of the VSTO runtime in detail.

In addition to these features, there are other enhancements you will benefit from like In-Process Side by Side and Improvements to NGen in .NET Framework 4.

Hopefully by now you are sold on targeting your solutions to .Net Framework 4 Smile.

There are also some changes that come with Windows 7 and Office 2010 that may affect your decision. Windows 7 now comes pre-loaded with .Net Framework 3.5 SP1; it benefits the developers who create customizations that target .Net Framework 3.5 SP1 because this pre-requisite is taken care of with its inclusion in the operating system. Additionally, the Office Runtime 3.5 extensions are bundled with Office 2010, and they are automatically activated if the users have .Net Framework 3.5 SP1 installed on their machines, check this blog post for details.

Hopefully this information will help you in making a more informed decision for targeting the appropriate .Net Framework version for your application.


Update: I was helping a customer with one of their Excel AddIn project and that reminded me another benefit of moving the VSTO Excel customization to .Net Framework 4.

All VSTO Excel solutions that target .Net Framework 3.5 SP1 or earlier use a locale proxy to solve a bug in Excel (http://support.microsoft.com/kb/320369) , this proxy adds performance overhead for each Interop call to Excel. Check out How VSTO solves the Excel LCID or Locale issue in the June CTP build for details.

VSTO Excel Customizations that target .Net Framework 4 do not need the local proxy and this improves the performance.