App-V and .NET: Pick a bubble, any bubble

Over the past week, I was tasked with investigating some of the "effects" of the .NET framework and related applications with the Microsoft App-V sequencing environment.

For those following the evolution of App-V (from the days of Softricity), the recent update of Microsoft's Application Virtualisation technology (App-V)  to 4.5 and version 4.6 saw a big change in the way that the .NET framework was sequenced with applications.

Life is really complex now, as I will demonstrate in the latter part of this blog, but life used to be simple (ahh, the good old days). Prior to the release of App-V 4.5 (and this includes the latest release of "service pack" update 4.6)  you could be forgiven for sequencing your applications with a version of Microsoft's .NET framework. Meaning that each individual App-B virtualized  "bubble" would include the required application and the required .NET dependency. Forgiven, but not encouraged. 

Given this rather lack state of sequencing Best Practices and rigour; a rather large number of people (and organizations) took the App-V 4.2 challenge and virtualized a good number of their applications. And, a good number of these App-V sequenced packages were .NET applications  that included their required version of the .NET framework.

The result. App-V 4.2 was a round for a while. And, these 4.2 App-V sequenced .NET application packages (including their dependant .NET frameworks) will be a round for a lot longer.

Let's flash forward to today. Flash!

App-V 4.6 is released and Microsoft releases the following update for .NET applications.

"Microsoft has made several architectural changes in the implementation of Microsoft Application Virtualization (App-V) 4.5 to ensure that the product is aligned with our roadmap for future innovation. One such change entailed moving the API intercepts from kernel mode into user mode. This change had a side-effect of changing the App-V compatibility with the .NET Framework from previous versions of App-V."

"App-V 4.5 continues to be fully compatible with .NET applications. The change in compatibility only manifests itself with the .NET Framework."

You can find the whole article here: http://technet.microsoft.com/en-us/appvirtualization/dd146065.aspx

Now, what this means is that all of the App-V packages that included .NET and were generated in versions  of App-V prior to 4.5 must abide by the following scenarios;

• Using and deploying applications that include the .NET Framework 3.5 (or earlier versions) is fully supported on Windows XP (SP2 and later) with App-V 4.5 CU1.
• For all other platforms, the client OS must have .NET locally installed. The installed version must be greater than or equal to the application’s .NET dependency
• Windows Vista RTM includes .NET 3.0 by default, no additional .NET installation is required unless the application requires .NET 3.5 RTM or SP1
• Windows Vista SP1 (fully-patched) includes .NET 3.0 by default, no additional .NET installation is required unless the application requires .NET 3.5 RTM or SP1

And to add to this (already complex) matrix , what about Server 2008 (R2)? ?And 64-bit platforms? How are they handled?

I was told by a Microsoft engineer last week, that App-V does not solve Operating system level application compatibility issues. With these kind of deployment scenarios and requirements/dependencies - no wonder they have taken this view.

Whew!