Scott Hanselman

SmallestDotNet: On the Size of the .NET Framework

August 24, 2008 Comment on this post [34] Posted in ASP.NET | Learning .NET | Musings | Windows Client | WPF
Sponsored By

Badge that says 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

imageLast night I made this website, 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. 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="" 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.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service
August 24, 2008 11:40
The new site is very helpful, thanks!

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?
August 24, 2008 11:59
Dimitris - Sure, I've made it work. I'll do a short write up next week. You need to select .NET 3.5 Client Profile in the Setup Project's Prerequisites in the Properties Box. It's not really intuitive, but it'll make total sense when I write it up in plain language. However, take a look at the Client Profile Deployment Guide which has a lot of good detail.
August 24, 2008 13:49
Really useful post, Scott and a great site. Thanks!
August 24, 2008 14:45
Hmm 60 Mb dl you say. How come I got a 73 Mb download then...? I vent to winupdate before visiting, fully patched.
August 24, 2008 23:01
Great! One question though do you ever sleep :-/. Or does your bed have a keyboard attached to it.. and you just write code while sleeping :P. I'm just kidding of course but you really are an amazing man.

Kudos. And I wish you all the best :-h good night
August 24, 2008 23:15
Hmm.... never mind the download size, the user experience still needs work. (Although I will fully acknowledge its come a long way from the "here's a scary Microsoft Download Redistributable web page" in .NET 1...)

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?
August 25, 2008 0:11
John - So far it's been my testing. It's obviously not bug-free. What can you tell me about your system so I can update my values? Did you have NO .NET at all on that machine? What OS? Help me out and I'll make it more accurate.

August 25, 2008 2:11
I'm a huge fan of this new 280kb bootstrapper. I'm using it for Paint.NET v4 and I'm now able to have a ZIP that has all prerequisites in about 3.7 MB: .NET 3.5 SP1 Client Profile, Windows Installer 3.1 (for those *fresh* XP SP2 boxes!), OpenMP, and Visual C++ 2008 SP1 runtimes (both x86 and x64). In combination with 7-zip / LZMA compression, that 3.7 MB actually unpacks to over 20 MB in the temp directory.

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.
August 25, 2008 3:54
Cool, Rick, we should collaborate on a series of best practices articles....

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.
August 25, 2008 11:00
Another way of reducing dot net downloads is using a commercial virtualization/linker product:

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.
August 25, 2008 11:40
Sandro - True, that's a good way to make things work for a *single* app, but if you've got dozens of apps, a single runtime is simpler. Thinstall is pretty sweet though.
August 25, 2008 18:43
Have you noticed this site "" (deliberately not giving them a link!) - seems a little... (can't find a word which the lawyers like!) to me, particuarly taking your entire feed and plastering it with their ads. I presume this isn't how you'd like your content used?
August 26, 2008 6:59
I have .Net 3.5 SP1, but when I view smallestdotnet with FireFox, the user agent says I only have .Net 2.0. Viewing the page in IE yields the correct results.

Here is the user agent from FF3 : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:; .NET CLR 2.0.50727) Gecko/20070725 Firefox/

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)
August 26, 2008 9:02
Jason - That is odd. However, that looks like Firefox 2, not Firefox 3. Can you confirm?

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?
August 26, 2008 18:13
I know for sure I am running FF 3.0.1. Not sure why the user agent says version 2. Very strange.
August 26, 2008 18:14
My mileage was a bit different, I'm on Vista 64bit and i've already got Net 3.5 installed. I got a small file, 2.8mb to download followed by 59Mb. What did I do wrong!!!
August 26, 2008 22:25
I was able to correct my FireFox problem by going into about:config and resetting the user agent override setting. The only thing I can surmise is that at one time in the past some FireFox extension must have changed my user agent. All is well now.
August 26, 2008 22:37
Scott, help!
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.)

August 26, 2008 23:58
Scott, maybe you are interested in Rick Brewster's experience with his installer for Paint.NET 4.0. He wrote an extensive post about integrating Windows Installer 3.1 and .NET Client Profile package just yesterday.
August 27, 2008 2:57
well, i read the article and thought, dotnet can't be that bad
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
August 27, 2008 3:07
This is one of those things that frustrates me to no end. I ship commercial software (my company's an ISV) and the .NET framework install process was already pretty bad circa 2.0. This was back in the days when we could ship a 20 meg installer that could install the whole thing. Now, with all the Service Packs and extra libraries the number of errors we see JUST from bad .NET framework installs is pretty high (probably around 5-10%) or so, which directly impacts our bottom line.

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?

August 27, 2008 17:51
Yes it's a 64-bit machine. I think I had some .net 3.5 beta version installed. I'm not sure though.
August 28, 2008 13:23
Me again. Thought you might want to know why your site (incl babysmash and smallestdotnet) hasn't been accessible from our company for two days.

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.

August 28, 2008 15:28

when browsing to 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)

August 28, 2008 19:17
Dig the site, great idea - however can I point out a typo "lastest stuff". Unless of course, it's a freudian slip and Microsoft are stopping development of .net at version 3.5 - what aren't you telling us ;-)
September 01, 2008 2:05
Why is it only you Scott who is trying to help with this confusion? Is everybody else in Redmond on vacation?

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!

September 01, 2008 20:24

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;
.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;

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;
.NET CLR 3.0.04506.30;
.NET CLR 3.0.04506.648;
.NET CLR 3.5.21022;
.NET CLR 3.0.4506.2152;
.NET CLR 3.5.30729;

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.
September 01, 2008 21:52
Firefox 3.0 running on XP with 3.5 SP1 installed reports it found when configured to report only the latest Framework version. In that case UserAgent string is:

Mozilla/5.0 (
Windows NT 5.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.
September 03, 2008 19:06
What bothers me completely: why Client Profile does not include Windows Installer 3.1?

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?

September 03, 2008 19:24
Got a Run time error when I clicked on the link

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\\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\\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
September 05, 2008 9:23
Hi Scott,
when reading the page
I got the following error: (Just below the Text Links)
The process cannot access the file 'd:\domains\\blog\SiteConfig\local_89718.xml' because it is being used by another process.


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 !!

September 18, 2008 5:54
Exact same experience as Tony -- with .NET Framework 2.0 already installed, the Client Framework installer stalled at 46% installed for over 5 minutes. I am sure there is scrambling going on behind the scenes to resolve this, but a little official comment on what the story is, and when we might expect to see a new build (or a workaround) would be extremely appreciated.

Thank you for the thoughtful discussion here, as always, and SmallestDotNet is a great concept.
September 26, 2008 20:49
Hi Scott,

I just used 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 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 the next time I need to upgrade!

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.