Scott Hanselman's Computer Zen - SmallestDotNet: On the Size of the .NET Framework

« ASP.NET Futures - Generating Dynamic Ima... | Main | The Case of the Failing Disk Drive or Wi... »

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.

Saturday, August 23, 2008 11:40:17 PM (Pacific Standard Time, UTC-08:00)

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?

Dimitris

Saturday, August 23, 2008 11:59:12 PM (Pacific Standard Time, UTC-08:00)

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.

Scott Hanselman

Sunday, August 24, 2008 1:49:33 AM (Pacific Standard Time, UTC-08:00)

Really useful post, Scott and a great site. Thanks!

http://kearon.blogspot.com/

Sunday, August 24, 2008 2:45:02 AM (Pacific Standard Time, UTC-08:00)

Hmm 60 Mb dl you say. How come I got a 73 Mb download then...? I vent to winupdate before visiting http://www.hanselman.com/smallestdotnet/, fully patched.

John

Sunday, August 24, 2008 5:02:25 AM (Pacific Standard Time, UTC-08:00)

Please, sir, may I have a linker?

Chris

Sunday, August 24, 2008 11:01:57 AM (Pacific Standard Time, UTC-08:00)

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

Mihai

Sunday, August 24, 2008 11:15:47 AM (Pacific Standard Time, UTC-08:00)

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?

Colin

Sunday, August 24, 2008 12:11:23 PM (Pacific Standard Time, UTC-08:00)

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.

Scott Hanselman

Sunday, August 24, 2008 2:11:48 PM (Pacific Standard Time, UTC-08:00)

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.

Rick Brewster

Sunday, August 24, 2008 3:54:58 PM (Pacific Standard Time, UTC-08:00)

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.

Scott Hanselman

Sunday, August 24, 2008 11:00:25 PM (Pacific Standard Time, UTC-08:00)

Another way of reducing dot net downloads is using a commercial virtualization/linker product:

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.

Sandro

Sunday, August 24, 2008 11:40:59 PM (Pacific Standard Time, UTC-08:00)

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.

Scott Hanselman

Monday, August 25, 2008 6:43:35 AM (Pacific Standard Time, UTC-08:00)

Have you noticed this site "http://www.5z5.com/Feeds/?a1117ee28d3d4274" (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?

Ian

Monday, August 25, 2008 6:59:13 PM (Pacific Standard Time, UTC-08:00)

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: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)

Jason

Monday, August 25, 2008 9:02:02 PM (Pacific Standard Time, UTC-08:00)

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?

Scott Hanselman

Tuesday, August 26, 2008 6:13:33 AM (Pacific Standard Time, UTC-08:00)

I know for sure I am running FF 3.0.1. Not sure why the user agent says version 2. Very strange.

Jason

Tuesday, August 26, 2008 6:14:11 AM (Pacific Standard Time, UTC-08:00)

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

Andy Tyrrell

Tuesday, August 26, 2008 10:25:11 AM (Pacific Standard Time, UTC-08:00)

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.

Jason

Tuesday, August 26, 2008 10:37:50 AM (Pacific Standard Time, UTC-08:00)

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

regards,
Radi

Radi

Tuesday, August 26, 2008 11:58:58 AM (Pacific Standard Time, UTC-08:00)

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.

thoemmi

Tuesday, August 26, 2008 2:57:54 PM (Pacific Standard Time, UTC-08:00)

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

alex

Tuesday, August 26, 2008 3:07:39 PM (Pacific Standard Time, UTC-08:00)

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?

Martin

Wednesday, August 27, 2008 5:51:34 AM (Pacific Standard Time, UTC-08:00)

Yes it's a 64-bit machine. I think I had some .net 3.5 beta version installed. I'm not sure though.

John

Thursday, August 28, 2008 1:23:03 AM (Pacific Standard Time, UTC-08:00)

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.

Radi

Radi

Thursday, August 28, 2008 3:28:35 AM (Pacific Standard Time, UTC-08:00)

Scott,

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

InsomniacGeek

Thursday, August 28, 2008 7:17:26 AM (Pacific Standard Time, UTC-08:00)

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

Ian

Sunday, August 31, 2008 2:05:07 PM (Pacific Standard Time, UTC-08:00)

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!

Tony

Monday, September 01, 2008 8:24:07 AM (Pacific Standard Time, UTC-08:00)

Scott,

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.

Tony

Monday, September 01, 2008 9:52:55 AM (Pacific Standard Time, UTC-08:00)

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

Tony

Wednesday, September 03, 2008 7:06:47 AM (Pacific Standard Time, UTC-08:00)

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?

Dejan

Dejan

Wednesday, September 03, 2008 7:24:57 AM (Pacific Standard Time, UTC-08:00)

Got a Run time error when I clicked on the link http://www.hanselman.com/smallestdotnet/

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

BrightNCalm

Thursday, September 04, 2008 9:23:54 PM (Pacific Standard Time, UTC-08:00)

Hi Scott,
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é

http://dautzenb.blogspot.com/

Wednesday, September 17, 2008 5:54:15 PM (Pacific Standard Time, UTC-08:00)

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.

Rob Burke

Friday, September 26, 2008 8:49:07 AM (Pacific Standard Time, UTC-08:00)

Hi Scott,

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!