Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio
All postings are provided AS IS with no warranties, and confer no rights. Additionally, views expressed herein are my own and not those of my employer, Microsoft.
The beta version of the .NET Framework 3.5 SP1 and Visual Studio 2008 SP1 were released a few weeks ago. One of the key new features related to deployment that was introduced with the SP1 beta is the .NET Framework 3.5 SP1 client profile. This profile is a subset of the full .NET Framework 3.5 SP1 installer that is designed to deliver assemblies needed in most common .NET Framework client applications. Enabling this type of refactoring was one of the motivations for the behind the scenes deployment architecture changes made in the .NET Framework 2.0 SP1 and 3.0 SP1 (described in more detail in this blog post).
This is a fairly big shift from the traditional .NET Framework installation process - in the past, it has always been an "all or nothing" installation, which means that an application could check one detection registry value and determine whether or not the full .NET Framework runtime is installed on a given system. Now, a system could have this client profile installed, which will only deliver a subset of the .NET Framework 2.0 SP2, 3.0 SP2 and 3.5 SP1. Application developers who redistribute the .NET Framework 2.0 or higher with their installer will need to decide how to take this profile into account in their detection logic.
The client profile is optimized for systems that do not yet have a version of the .NET Framework 2.0, 3.0 or 3.5 installed. Here is a quick summary of how the installer for the client profile will behave in various scenarios:
The client profile also has implications on existing applications that include previous versions of the .NET Framework 2.0, 3.0 or 3.5 as a part of their installers. If a system has the client profile installed, they have a partial install of the .NET Framework 2.0 SP2, the .NET Framework 3.0 SP2 and the .NET Framework 3.5 SP1. If an application later attempts to install the original release of the .NET Framework 2.0, 3.0 or 3.5, that would leave the system with a hybrid .NET Framework - some of the bits would be from the original release and other bits would be from a service pack. In order to avoid that hybrid state, the client profile setup configures some settings behind the scenes to prevent installation of any older versions of the .NET Framework 2.0, 3.0 or 3.5 on a system that has the client profile installed.
It looks like there are still some bugs that need to be worked out in this process though. I was able to to install the client profile on my Windows XP SP2 test machine with no issues. However, when I try to run the original .NET Framework 2.0, 3.0 or 3.5 setup, the system attempts to invoke the file %windir%\Microsoft.NET\Framework\v3.5\DotNetInstallBlock.exe and that process crashes. Also, if I try to run .NET Framework 1.0 or 1.1 setup on this system, it still tries to invoke DotNetInstallBlock.exe even though this client profile should not need to block installations of versions 1.0 or 1.1 of the .NET Framework.
Since this client profile is still in beta, there is not a lot of official documentation available for it yet. However, here are a few useful links I've found so far that provide some additional detail about the client profile:
For reference, here are some other useful links for Visual Studio 2008 SP1 and the .NET Framework 3.5 SP1:
Last week, I started looking at the beta version of the .NET Framework 3.5 client profile in more detail
Question: I am creating an application that is built on the .NET Framework 2.0, and I am attempting to
As mentioned yesterday .NET Framework 3.5 SP1 and Visual Studio 2008 SP1 were released. Here is a more