SmallestDotNet: On the Size of the .NET Framework
There's been some confusion about the size of the .NET Framework. The .NET Framework is not really a 200+ meg download.
Which installer do I use?
Here's the whole thing in a nutshell for Developers, ISVs, and Administrators.
- Offline Installer - One single file that can be run offline and can install the .NET Framework any system it's run on. It's complete, all platforms, installable offline.
- Online Installer - A 2.7 meg setup program that will detect what just the files you need, then go download between 10 and 60 megs.
- NOTE: If you're IT and inside an office, you'll want to decide if you want everyone in the office downloading .NET separately, or if you just want download it once, and have them to run it off a network share. Check out the Deployment Guide for Administrators for ways to push it out via AD or SMS.
So how big is it the .NET Framework download, really?
It depends on what you've already got installed. Here's some examples of my results using an XP SP2 machine.
| Version of Framework installed | Download size to get to 3.5SP1 | Time to Download (512 kbps) |
| None | ~56 MB | 15 min |
| 2.0 | ~50 MB | 15 min |
| 2.0SP1 | ~33 MB | 9 min |
| 3.0SP1 | ~10 MB | 3 min |
From a download perspective, those numbers aren't too bad. It's not nearly as bad as its been made out to be. I'm not saying this as a Microsoft apologist or paid Microsoft shill, I'm showing the numbers that I have seen in my testing. This is my opinion based on my testing.
However, as a free-micro-ISV myself, and the distributor of a .NET Client Application, namely BabySmash!, I'd like the download size to me as SMALL as possible. I've personally received the same emails many of you have - "I'd love to download your software but I don't want to download a 200 meg .NET Framework." I'd like to help change that perception to get more people to run BabySmash! and the best way to change negative perceptions is to improve reality. ;)
Online/Download Experience
The best way to get a user with reasonable Internet connectivity up on the 3.5 SP1 .NET Framework is with the 2.7 Meg "bootstrapper." This will detect what they need and only download what they need. The worst-case scenario for a x86 machine is around 60 megs, as seen in the table above.
What's the "Client Profile?"
The Client Profile is an even smaller install option for .NET 3.5 SP1 on XP. It's small 277k bootstrapper. When it's run on a Windows XP SP2 machines with no .NET Framework installed, it will download a 28 meg payload and give you a client-specific subset of .NET 3.5. If the Client Profile bootstrapper is run on a machine with any version of .NET on it, it'll act the same as the 3.5 SP1 web installer and detect what it needs to download, then go get it. There's more details in the Client Profile Deployment Guide.
Ultimately, this will be the best and fastest possible way to get the .NET Framework, as it's smart on each platform. I'm going to move BabySmash to the Client Profile to get new XP customers up on .NET more than twice as fast with less than half the total download size.
The Client Profile Offline Installer (Preview) that Chris noticed was big was such because it is another example of an offline installer. It is the Client Profile Setup + the Full Installer mentioned before. Again, this particular download is totally for offline only scenarios. Unless you need a completely offline scenario, neither you nor your users need download it. The Client Profile Bootstrapper and its associated customization tools will be released soon.
Offline Experience
Now, from an offline perspective, if you're on a CD/DVD if you want to make sure that any machine you come upon will be able to get up to .NET Framework 3.5, you'll want the super offline installer. However, you can and should modify that offline installer to make it as smaller as you need. If you only support x86, then only ship those bits. Aaron Stebner points out that you can :
Extract the contents of the full install package and selectively remove payload that is not needed or supported by the scenarios that the setup that requires it supports. I describe this option in a bit more detail in this blog post. At a high level, this option involves identifying supported OS's and processor architectures and then selectively removing prerequisite payload from the .NET Framework 3.5 install location for platforms that the setup carrying the .NET Framework 3.5 does not plan to support.
He's basically saying for administrators and IT folks should customize the .NET Framework installer to yank stuff you don't need. This kind of customization and more is going to be easier later in September when the .NET Client Profile Configurator is released, so watch for that.
Why is that one installer so big?
That giant .NET download is for one thing - It's meant for developers or administrators who might want to redistribute a a setup that contains not just the whole of the .NET Framework, but for all possible platforms. It has installers for x86, x64 and ia64. As mentioned above, you can customize it and make it smaller, shipping just what you need, based on your product's needs.
I've brought the total size up to bosses who care, as have many other smarter people and it's and making the installers even smaller, via separation, compression and other ideas are being actively looked at.
Windows Update
Over the next several months, machines with .NET 2.0 and up will start updating to the latest .NET 3.5SP1 using Windows Update. For ISVS (like me) this'll start to level versioning out so I'll know more about what's on the average user's machine. For example: If a machine already has .NET 3.5 on it, BabySmash is a small 1 meg download, which makes BabySmash, and me, look good.
Introducing SmallestDotNet.Com
Last night I made this website, SmallestDotNet.com to help out. It'll sniff your browser's UserAgent and tell you want version of .NET you have, how big the download would be to get you to .NET 3.5 and what .NET redistributable is best for you in order to minimize your download. As some newer online deployment options are released I'll update the site's sniffing to make sure that sizes and choices are is optimal.
SmallestDotNet.com also has some Javascript that you can add to your product's sites as an include, that can help let users know how big the download for .NET will be ahead of time, an lead users to the right downloads, like this:
<script src="http://www.smallestdotnet.com/smallestdotnet/javascript.ashx" type="text/javascript"></script>
It's not perfect, as it has only the UserAgent to base it's guess on. However, I've found it useful on BabySmash! and I hope you find it useful too.
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
Kudos. And I wish you all the best :-h good night
I tried installing it from the 2.8meg setup.exe, and the download counter was a mess... it would start off at 0/53MB, download a few megs, reset to 0/53MB, download some more, reset to 0.... eventually it jumped to 43megs (after to resetting to 0 a few more times) and finished off the download. It actually downloaded relatively quickly (within a minute or three over my cable modem) but if I was an actual user, I would've hit the cancel button a long time ago on the assumption the download was broken. (Yes, I'm sure the download counter resets because there's different packages its downloading or something, but there's no indication of that and it's in no way an acceptable excuse.)
So that was a bit of a bust.
Then I tried resetting my VPC snapshot and installing the .NET Framework directly from the Babysmash installer. That was even worse... a message about "Please wait while setup configures the system", absolutely no download progress indicator, the only way I knew anything was happening was I could see the network activity.
So, neither of those experiences are really what you'd want to put on an internet-downloaded application, there's just too much risk of a customer assuming they're broken and hitting the cancel button.
Very disappointing, especially for a "going to get the client experience right" Service Pack release. Is this going to be improved in the September Client releases? Are there going to be continuing efforts to "get this right"? Given the complexity of the framework at this point, will there be opportunities for 3rd party vendors to (ie. InstallShield *ick*) to improve the .NET3.5 download experience, or are they pretty much dependent on what Microsoft gives them?
Although, I've found there are two extra tricks you have to learn to use the client profile. The first is that you have to detect .NET differently: since client profile is a subset of .NET, it does not put the registry entries that claim .NET 2.0+3.0+3.5 is installed. Second, if you aren't already, you now have to distribute the *.exe.config files so that the runtime can detect things correctly as well. This can be a bit of a trick to remember for your installers and updaters.
I think I need to add different sizes for 64-bit and 32-bit machines, I suspect the 74meg download was for a 64-bit machine.
http://www.thinstall.com/solutions/net_virtual.php
http://www.xenocode.com/Products/Postbuild/
Basically these products will analize your executable assembly and reduce the dot net framework to the necessary components. This probably will produce the SmallestDotNet. I have no association to these products and have not run any tests on it. I simply wanted to mention it as another viable possibility for people to reduce the footprint of their installer packages.
Here is the user agent from FF3 : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6; .NET CLR 2.0.50727) Gecko/20070725 Firefox/2.0.0.6
Here is the user agent from IE7 :Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; InfoPath.1; .NET CLR 1.1.4322; .NET CLR 1.0.3705; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; MS-RTC LM 8; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Ian - I'll talk to the guys at that domain and get my feed removed. Thanks for the heads up.
Colin - I'll make sure the right people see your feedback and are aware of what improvements need to be made.
John - Was that 32- or 64-bit?
I've been reading your blog regularly from my office, but as of yesterday or maybe the day before yesterday, I'm not able to get your blog on my office screen anymore. Your site is blocked by our ironport software which says: "MALWARE_GENERAL, BLOCK-MALWARE. This site is dangerous for your PC or your oranization. This site contains malware/spyware. This site will not be displayed."
Any idea?
(I still read your blog, BTW, I just have to google it and then read the Cached version - but no images etc.)
regards,
Radi
i am a developer so i am used to installing dotnet, service packs etc
(yes i acknowledge the software is free, i am not complaining, just listing my comments)
i installed babysmash at home to see how it goes. the installer said approx 10mb, the download didn't take very long
but it took forever to install, then i had to reboot, and then it did some more installing stuff, then windows started and i got a warning, trying to run babysmash, so i clicked ok, and it started installing babysmash. by that time i had to go to work, so i guess i won't see what it is like until tonight.
dotnet it does seem like a lot hoops to jump through just to get a small program to try out, a bit of a shame really
and i am running vista with the latest service packs, so i can only imagine how long it will take someone with an older machine
Moreover, these installers that download stuff on demand cause HUGE problems for anyone behind a proxy server or anything like that (probably another 20% or more, for us). So basically, shipping an installer like PaintDotNet does or like the one you're suggesting pretty much means that we'll have a pretty good chance of losing 25-30% of our potential customers just because they can't install the framework!!
It seems like there's been this movement inside Microsoft in reaction to the DLL Hell problems of the old days to fix these with the heavy hand of just shipping the kitchen sink and this has resulted in these massively ballooning installers like 230 megs for a .NET Framework and 2.5 Gigs for SQL Server and so on...
This is just flat out the wrong way to do things! It's not like (especially for features like LINQ and other libraries) like we just couldnt plop the DLLs in our directory and have everything work... Instead, the powers that be have forbidden this in the EULA thinking it's better to make us pay for 210mb overhead just to get LINQ. It's like Microsoft has intentionally crippled the framework for client development.
And while we're on the topic of the Client Framework, it only works for people that don't have ANY .NET framework installed. Got 2.0 already installed? You need the full 3.5 framework. That makes this thing next to useless. I can only imagine what will happen when .NET 4.0 comes out. Are we going to get a 1GB installer? I think the real problem here is that Microsoft is not dogfooding any of this. I can't think of any MS products that ship the installer, so nobody deals with these problems first hand.
I want LINQ, but I dont want to ship a 230 MB installer. Is that really that unreasonable?
According to our admins this was due to our IronPort and their (kind of) blacklist. They also have something called web reputation technology where they scan the web and try to figure out who's bad. Obviously, since I can view your site again, the list has been updated. - Don't know if this affects anyone outside of IronPort protected company/enterprise environments.
Radi
when browsing to SmallestDotNet.com using Windows 2000 (please don't ask why I'm doing that...) it tells me to upgrade to .NET Framework v3.5 SP1. However, the .NET Framework v3.5 SP1 can't be installed on Windows 2000.
User-agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
/Magnus
Anyway, my experience with Client Profile installation targeting NET 3.5 SP1 is definitely confusing.
On XP machine with no Framework installation took about 15 minutes. That was what I was hoping for!. Great!
However, running the same setup.exe on XP with Framework 2.0 already installed took 54 minutes! That was very disappointing and led me to conclude that it doesn't make sense to bother with Client Profile since it is targeting one OS configuration that, in my case, in not so common to justify a special UI experience that you get with Client Profile bootstrapper.
Posting about this in two Windows installation-related forums I get the impression that I am one of the few persons on this planet who ever performed such tests. I would gladly have somebody tell me : 'you messed up something! I did the same thing as you did and it took even less time to install 3.5 when Framework 2.0 was already installed than when it wasn't'.
The problem is: nobody does!
there is a problem detecting Framework 3.5 SP1 on XP machine, while on Vista it is fine.
Here is comparison of messages and User Agent strings on Vista and then XP:
Looks like you have .NET version 3.5 SP1.
That's the VERY latest .NET Framework.
You don't need to do anything right now
Mozilla/4.0 (compatible;
MSIE 7.0;
Windows NT 6.0;
SLCC1;
.NET CLR 2.0.50727;
.NET CLR 1.1.4322;
.NET CLR 3.5.21022;
.NET CLR 3.5.30729;
.NET CLR 3.0.30618;
MS-RTC LM 8)
For XP:
Looks like you have .NET version 3.5.
The latest version is 3.5 SP1
Mozilla/4.0 (compatible;
MSIE 7.0;
Windows NT 5.1;
.NET CLR 1.0.3705;
.NET CLR 1.1.4322;
Media Center PC 3.1;
.NET CLR 2.0.50727;
IEMB3;
.NET CLR 3.0.04506.30;
.NET CLR 3.0.04506.648;
.NET CLR 3.5.21022;
MS-RTC LM 8;
.NET CLR 3.0.4506.2152;
.NET CLR 3.5.30729;
IEMB3)
Note that the greatest CLR 3.5 build number is the same on both machines. In fact, I know that my XP has SP1 installed because I can see it in Add/Remove Programs plus I upgraded that XP from 3.5 to 3.5 SP1 using the link on your site.
Mozilla/5.0 (
Windows;
U;
Windows NT 5.1;
en-US;
rv:1.9.0.1)
Gecko/2008070208 Firefox/3.0.1 (.NET CLR 3.5.30729)
However, if configured to report all Freamework versions web page reports that only 3.5 is installed. My guess is that a mixture of 3 parts and 4 parts version numbers confuses the script parsing UserAgent.
It is nice that bootstrap is so small, that it can be downloaded as offline version too, but why having pre-requisite Windows Installer 3.1 instead of making it part of Client Profile?
Dejan
The error is
Version string portion was too short or too long.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.ArgumentException: Version string portion was too short or too long.
Source Error:
Line 18: getdotnet.HRef = Constants.dotnet35url;
Line 19:
Line 20: Version version = Request.Browser.ClrVersion;
Line 21: if (version != null && version.Major != 0)
Line 22: {
Source File: d:\domains\hanselman.com\smallestdotnet\Default.aspx.cs Line: 20
Stack Trace:
[ArgumentException: Version string portion was too short or too long.]
System.Version..ctor(String version) +2743958
System.Web.Configuration.HttpCapabilitiesBase.GetClrVersions() +376
System.Web.Configuration.HttpCapabilitiesBase.get_ClrVersion() +4
_Default.Page_Load(Object sender, EventArgs e) in d:\domains\hanselman.com\smallestdotnet\Default.aspx.cs:20
System.Web.Util.CalliHelper.EventArgFunctionCaller(IntPtr fp, Object o, Object t, EventArgs e) +15
System.Web.Util.CalliEventHandlerDelegateProxy.Callback(Object sender, EventArgs e) +33
System.Web.UI.Control.OnLoad(EventArgs e) +99
System.Web.UI.Control.LoadRecursive() +47
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1436
I got a 400 bad request for http://www.smallestdotnet.com
when reading the page http://www.hanselman.com/blog/SmallestDotNetOnTheSizeOfTheNETFramework.aspx
I got the following error: (Just below the Text Links)
The process cannot access the file 'd:\domains\hanselman.com\blog\SiteConfig\local_89718.xml' because it is being used by another process.
mscorlib
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy) at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize) at System.Xml.XmlDownloadManager.GetStream(Uri uri, ICredentials credentials) at System.Xml.XmlUrlResolver.GetEntity(Uri absoluteUri, String role, Type ofObjectToReturn) at System.Xml.XmlTextReaderImpl.OpenUrlDelegate(Object xmlResolver) at System.Threading.CompressedStack.runTryCode(Object userData) at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData) at System.Threading.CompressedStack.Run(CompressedStack compressedStack, ContextCallback callback, Object state) at System.Xml.XmlTextReaderImpl.OpenUrl() at System.Xml.XmlTextReaderImpl.Read() at System.Xml.XmlLoader.Load(XmlDocument doc, XmlReader reader, Boolean preserveWhitespace) at System.Xml.XmlDocument.Load(XmlReader reader) at Hanselman.TextLinkMacro.TextLinks(String adID, String inventoryKey)
BTW: I like your amazing podcast !!
Cheers,
André
Thank you for the thoughtful discussion here, as always, and SmallestDotNet is a great concept.
I just used SmallestDotNet.com to grab the installer for 3.5 SP1. You deserve credit for building a site that offers the "fastest dot net" too. I didn't have to waste time searching for the install files on our network, or on Microsoft.com. In about 10 seconds I was downloading the installer and in less time than it took to write this note, I was upgraded to the latest version. Also, I wasn't quite sure if the machine had 3.5 or just 3.0, and your site answered that question pretty quickly.
I'll definitely be back to smallestdotnet.com the next time I need to upgrade!
Comments are closed.
How does one integrate properly the Client Profile bootstrapper to the Setup project of a desktop application?
I am asking because I have been trying to create a Setup project with the Client Profile being the only selected prerequisite. The idea being that, upon running the generated MSI file, the bootstrapper automatically fetches the Client Profile as part of the overall app installation process. (My own experience being that the manual download & installation of .NET is one of the bigger barriers to getting users to even try out the application).
On the "Specify the install location for prerequisites" selection, if I select "Download prerequisites from the component vendor's web site", the Setup project does build properly; however, upon running the generated MSI file I get prompted to download the .NET updates manually from the MS site, which arguably defeats the whole purpose of a smooth user experience.
OTOH, if I select any of the other two selections, upon building the Setup project the following error message is thrown:
"The install location for prerequisites has not been set to 'component vendor's web site' and the file 'DotNetFx35Client\DotNetFx35ClientSetup.exe' in item '.NET Framework Client Profile' can not be located on disk. See Help for more information." (Typically, Help is not of much use).
So, either I am doing something wrong (probably) or the Client Profile bootstrapper cannot be integrated into the app install process.
Has anyone managed to make this work?