How big are various CLR runtimes?

Question

I'm considering migrating a project to managed code, but I've heard that the .NET runtime is huge--several times larger than my executable binary, in fact. That just seems like the tail wagging the dog to me. But I've also been told that some CLR implementations, such as Mono, are modular, and you can create a custom distribution for them that only contains the parts you actually need.

Problem is, I'm having a surprisingly difficult time finding answers on Google to what ought to be very simple questions about this. How big are the full CLR packages on various implementations, which ones support this modular distribution ability, and how big would the runtime end up being for a standard windows-style (form-based) app that doesn't use tons of .NET bells and whistles? (Mostly what I'm interested in is the Assembly system's inherent ability to create plugins easily, and the ability to build scripting into my program through JIT compilation.)

EDIT: I'm not interested in installer sizes or download times. I want to know the size of the actual framework, uncompressed and ready to run, as it will be on the end-users' systems.

Answer 1

You might find this site interesting.

http://www.hanselman.com/smallestdotnet/

Answer 2

Scott Hanselman has a useful blog post on the size of various .NET distributions, and the impact of these on software distribution.

Answer 3

The CLR runtime is installed when the framework is installed. If I recall correctly .NET 2.o's installer is somewhere around 35-40Mb in size. I am not sure about 3.0 and 3.5, you could look out on the Microsoft downloads to get an idea.

It is becoming more and more common for the framework to be installed already, and since it is a service used by other applications, often it isn't considered part of your applications footprint by many.

I am not aware of any way with the Microsoft version to make it "modular"

Answer 4

What you have to realize is that every language will need some sort of CLR. Even if it's C/C++, it depends on the one built-in to the operating system. Java's version is the JVM, and of course there's the .NET versions. If you're really worried about size, someone linked smallest .NET, and that's a good start.

Just remember that most people will already have at least .NET1.0 installed, and unless portability is extremely important to you it's best to just state the .NET framework is a dependence.

Answer 5

Hi Mason,

Normally, you shouldn't worry about the size, as most of the Internet connected computers that have genuine Microsoft Windows and are set to retrieve Automatic Updates should have the framework installed. To be sure, I would recommend you version 2.0, as it seems that it is the most popular. Also, take in mind that there is a smaller version (subset) of the .net framework called the "client profile".

Also think about this: If you are using any outside libraries (i.e. MFC/ATL/VB Runtime)? If you are, with these dependencies included, your application might reach the same size as with the .net framework, if not bigger.

Indeed, there would be a problem with older systems (pre 2000 SP4) but this depends on your target customer and finally of your aims.

Later edit: You can set your application's installer to automatically download the required dependencies (the version needed for your application), and also, you can use the ClickOnce technology for deploying and maintaining your application relatively easy from a web site (by providing updates).

Answer 6

A route you can look into is a tool that converts to C++ like http://www.codeplex.com/crossnet. Not feature complete or perfect per se, but will allow you to program higher level and then have the freedom of being .Net free.

Answer 7

I see you want "disk used when installed" not "download size". This is not a particularly useful thing to measure, and the answer is "You basically can't tell", but here's my data for interest's sake:

Looking in my windows directory, in the Microsoft.NET\Framework directory (which is where the frameworks all live), on my windows vista PC, I have the following directories:

• v1.0.3705: 400 k
• v1.1.4322: 493 bytes

Note however, I don't actually have these frameworks installed. Vista probably just has some aliases for compatibility. You would never develop using these versions anyway as they're obsolete (and crap, in comparison to the newer stuff)

Now here's where it gets interesting.

• The 'Framework' directory itself has 356 k of files
• v2.0.50727: 152 MB
• v3.0: 10.5 MB
• v3.5: 24.7 MB

There's also the 'global assembly cache' in C:\Windows\assembly, which on my PC runs to 530 MB, BUT some of those files are hardlinked into the other directories, so they don't count.

This is misleading however, as 3.0 and 3.5 run "on top of" 2.0, and you can't have them by themselves.

That's the raw data, but it's not as simple as just looking at the numbers like that.

1. I have visual studio 2005 and 2008 installed. That gets me hundreds of MB of debug dll's.

2. There is also the Microsoft Visual J# 2.0 Redistributable Package which is part of installing visual studio, and not required on client PC's unless you use J# which nobody ever does. That's 7 MB

3. In addition to the debug copies of all the dll's, there is also XML documentation files, which total 69 MB in the framework\v2.0 directory

4. Anyone with Vista will already have the v2.0 and v3.0 directories, and their v2.0 directory will be quite a bit smaller unless they've also installed .NET 3.5. Unless you're targeting .NET 3.5 specifically, the "deployment cost" on Vista is therefore Zero.

For some more realistic 'client' data, I have a Windows XP SP2 PC with a basic install of .NET 2.0 only. Here's the numbers on that:

• Windows\Microsoft.NET\Framework\v2.0.50727: 64 MB
• Windows\assembly: 92 MB (note it's not really this big due to hardlinking)

I remember seeing '130 megabytes required' some time ago for .NET 2.0 on winXP, which sounds about right.

Now, this sounds like a lot, but here's some data to contrast it with:

The VC++ 2008 base dll's (vc, mfc, atl) are 10 meg, and they give you very little in the way of features. By the time you build a C++ application with any decent featureset, in my experience you're looking at around 4-5 meg of executables and dll's that you're shipping. In contrast, a comparably featured .NET app I built a while ago had 800k of dll's and executables, most of which were taken up with embedded icons and bitmaps.

It doesn't require all that many apps these days before the .NET runtime starts being a net win.