The .NET Framework Size Debate

In his latest entry Christopher Painter discusses the .NET Framework distribution size and the complications of distributing the framework.

The "accepted" practice has usually involved embedding the .NET Framework with your installation via a wrapper. This becomes complicated with the ever increasing size of the redistributable. There are other problems that can arise and not to mention, it violates the EULA.

If you take the time to read through the EULA, you will see that you are accepting some pretty hefty stipulations (and making some assumptions) on behalf of the user by silently installing the .NET Framework for them. If you are in any kind of software development or enterprise IT role, you should really take the time to read through the Microsoft Patterns and Practices. Some of the best practices may seem over the top and excessive, but it will provide a good baseline to begin from.

I don't disagree with Chris on any particular point in his blog, but if it were up to me, I would suggest detecting if the .NET Framework is present and either directing the user to the download site or providing it on your distribution media if you are redistributing from hard media.

So...how do you do that? I'll show you how to detect the presence of the .NET Framework and cancel your installation if it is not detected. For the purposes of this article, we'll assume that you need to search for version 2.0.

Microsoft has provided a support article that describes the best method for detecting the required version of the .NET Framework.

Many Windows Installer development products have built in methods for detecting the existence of the .NET Framework, but in case your's does not, here it is. The first thing you will need to do is populate the RegLocator table:

RegLocator Table
Signature	Root	Key	Name	Type
AppReg	2	SOFTWARE\Microsoft\.NETFramework\policy\v2.0	50727	2

We are telling the installation to search for the designated registry key, and populate a property with its value if it is found. The property to be populated is defined in the AppSearch table:

AppSearch Table
Property	Signature
DETECTDOTNOT20	AppReg

If you would like to use the results of this search in a Launch Condition, you will need to ensure that the AppSearch action is sequenced before the LaunchConditions action in both the InstallUISequence and InstallExecuteSequence tables. Keep in mind that a LaunchCondition is a no frills way to boot the user out of an install. It will not give the option to ignore the error and continue; it's a pass/fail system. Any other method would either require a customer installer dialog or a custom action. With that in mind, if you would like to use the LaunchCondition table, here is how to populate it with the given example:

LaunchCondition Table
Condition	Description
DETECTDOTNET20="50727-50727"	[ProductName] requires Microsoft .NET Framework 2.0 in order to function properly. Setup will now terminate.

I find this method superior to cramming the redistributable in your installer. It saves space, reduces failure points, and adheres to the EULA.

Feedback

# re: The .NET Framework Size Debate

I've read DALG ( Deploying .NET Applications LifeCycle Guide ) from MS P&P and personally I think it's almost a complete joke. It's full of anti patterns ( VDPROJ, Installer Class, IIS VBScript's for IIS Metadata manipualtion ) and barely touches the EULA issues while giving the command line for a silent install and mentioning that "rather then manually ensuring dependenies such as MDAC and WMI are correctly installed...you might want to build checks into your setup routines...automatically install them along with your application." ( Page 20 )

Then again, it also mentions common dependencies such as IIS/ASP.NET that are Windows System Components that you can't redistribute.

Then again, I particularly love the part ( Page 130 ) where they have you making VDPROJ patches using administrative installs, Orca and Msimsp.exe.
12/28/2007 2:36 PM | Christopher Painter

# re: The .NET Framework Size Debate

Aren't installation usually the definition of anti-patterns? ;-)

In referring to the Patterns and Practices, I was referring to more of an overall guideline. The portions discussing installations are iffy at best, and they are focusing strictly on Microsoft products. We all know that there really is no such thing when it comes to installations. There are utilities, but no true installer product has ever been delivered by Microsoft.

WiX is the closest thing, and is approaching product status with its inclusion in VSTS 2008. I love WiX, but it's definitely not an "every man's" tool. There are some things that make integrating it into your development projects a real pain in arse.

It would be interesting to see one of the smaller installation shops get gobbled up by Microsoft and have a real focus on integration and installation best practices. 12/28/2007 3:41 PM | AJ Shurts

# re: The .NET Framework Size Debate

QUOTE:
but if it were up to me, I would suggest detecting if the .NET Framework is present and either directing the user to the download site or providing it on your distribution media if you are redistributing from hard media.
ENDQUOTE

While I can understand the best practices and such, the perspective from an ISV is that not installing DotNet as a prerequisite when your app requires it makes for a horrible user experience.

Microsoft's Vista mantra is improving the user experience. This suggestion frankly provides the worst possible user experience. Yes, I do provide DotNet on my media however, if I don't launch the install myself many of our customer base may not know how to manually get in and launch the setup themselves.

Even Visual Studio has a chainer / prerequisite installer where it loads many prerequisites for you. So why would you expect the ISV to do any different. When Microsoft develop these packages redistributing the package should be part of the consideration especially for items that are foundational and required for software development / deployment.

Just a couple of thoughts on this. 2/26/2008 4:35 PM | Dan Lee

Demystifying Windows Setups