Partilhar via

How the full install packages for the .NET Framework 3.0 and the .NET Framework 3.5 differ

  • Artigo

Question:

When the .NET Framework 3.0 shipped, 3 packages were made available for download - a 2.8 megabyte web download bootstrapper, an approximately 50 megabyte full install package for x86 processor architectures and an approximately 90 megabyte full install package for x64 processor architectures.

When the .NET Framework 3.5 shipped, 2 packages were made available for download - a 2.7 megabyte web download bootstrapper and an approximately 200 megabyte full install package.

Why is the .NET Framework 3.5 full install package so much larger than the 3.0 full install package, and what exactly does it contain?  If I need to redistribute the .NET Framework 3.5 as a part of my installer, do I have any options to reduce the size?

Answer:

The .NET Framework 3.5 full install package includes all prerequisites and product components that could need to be installed for any processor architecture.  Basically, it is the union of the x86, x64 and ia64 packages and prerequisites.  The .NET Framework 3.5 includes the following prerequisites in addition to the main .NET Framework 3.5 product payload:

  • .NET Framework 2.0 with SP1
  • .NET Framework 3.0 with SP1
  • MSXML 6.0
  • RGB Rasterizer
  • Windows Imaging Components (WIC)

The 200 megabyte full install package was not really designed to be redistributed as is by installers that require the .NET Framework, although it will work fine for that purpose if the installer does not have any sensitivity to the larger package size.

Installers that want to reduce the .NET Framework 3.5 payload size have a couple of options:

  1. Carry the web download bootstrapper and let it decide what payload is needed based on the state of the system it is being installed on.  This can be a good option if it is acceptable for the setup to require internet access during installation.
  2. 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.

There is some more specific .NET Framework 3.5 deployment documentation that will be published soon to provide more details about how to redistribute the .NET Framework 3.5 in various types of scenarios.  The prerequisites and install options will be described in much more detail than I am going into in this blog post once it is published.  I will update my blog with a link to the .NET Framework 3.5 deployment guide once it is available.

As a side note, I have seen some size comparison charts that show the .NET Framework size growing from 20 megabytes in 1.0 up to 50 megabytes in 3.0 and then 200 megabytes in 3.5.  It looks like this type of size chart was based on the size of this full install package for the .NET Framework 3.5.  That isn't really an accurate comparison though.  The 50 megabyte size for the .NET Framework 3.0 only includes x86 components, so an equivalent size for x86 components for the .NET Framework 3.5 is approximately 57 megabytes.  That means that the size of features that are new between the .NET Framework 3.0 and 3.5 is approximately 6 or 7 megabytes.  That is still fairly large for something that has to be redistributed by other installers for their applications to use at runtime, but it is not nearly as dramatic as saying that the .NET Framework 3.5 is 200 megabytes in size compared to 50 megabytes for the .NET Framework 3.0.

Comments

  • Anonymous
    January 10, 2008
    PingBack from http://geeklectures.info/2008/01/10/how-the-full-install-packages-for-the-net-framework-30-and-the-net-framework-35-differ/

  • Anonymous
    January 10, 2008
    PingBack from http://msdnrss.thecoderblogs.com/2008/01/11/how-the-full-install-packages-for-the-net-framework-30-and-the-net-framework-35-differ/

  • Anonymous
    January 10, 2008
    PingBack from http://msdnrss.thecoderblogs.com/2008/01/11/how-the-full-install-packages-for-the-net-framework-30-and-the-net-framework-35-differ-2/

  • Anonymous
    January 10, 2008
    It's clearly correct at some level to assert that comparing 200M to 50M is unfair or inaccurate.  However, that you should have put people in the position of needing  to make such a comparison is an illustration of a real blind spot MS has about the way people feel about the size of the .NET redistribution. .NET is supposed to be the technology that MS has bet the farm on, but you've always seemed woefully careless about the challenges people have in trying to get the framework deployed on to their customers' machines.   Bundling 60MB of IA64 files for goodness sake!!!!  I doubt I'll ever meet anyone who ever owned an IA64 machine, let alone installed the 3.5 framework on it.   Why not chuck in the Alpa, PPC and MIPs images that work with NT3.51 while you're at it? I just wish you guys could see what some of this stuff looks like from the outside.

  • Anonymous
    January 11, 2008
    Hi Willdean - The full install package for the .NET Framework 3.5 is just that - a full install package that contains all possible payload.  Most customers won't need to redistribute ia64 bits, but some will, so they have to be included in a full install package. The main thing that I think is missing from the .NET Framework 3.5 release is separate "full" install packages for each processor architecture like the ones for 3.0.  Those can be assembled by removing the ia64 bits from the all-architecture full install package, but that does require additional steps that are new in 3.5.  Unfortunately, the deployment documentation that walks through how to do that hasn't been published yet. One thing to note too - back in 3.0, the full install package for x64 contained some duplication of bits from the x86 package.  That meant that developers who needed to redistribute both x86 and x64 would have to redistribute some duplicate payload to make that possible.  This duplication is eliminated in 3.5, so x64 will essentially use the same payload as x86 plus the additional x64-specific payload it needs.

  • Anonymous
    March 27, 2008
    PingBack from http://ramsonit.wordpress.com/2008/03/27/net-35-runtime-distribution-size/

  • Anonymous
    June 29, 2008
    PingBack from http://www.edugeek.net/forums/windows/21465-post-xp-sp3-update-pack.html#post210436

  • Anonymous
    December 23, 2008
    Back when the .NET Framework 3.5 shipped, I posted a brief explanation about the size and contents of

  • Anonymous
    February 09, 2009
    >> The main thing that I think is missing from the .NET Framework 3.5 release is separate "full" install packages for each processor architecture like the ones for 3.0 Definitely! We have a comparedly small user base, but still "disconnected setup" are quite common. If the user the user receives CD, he simply expects "everything to be on it", whether he has internet or not. Distribution size is always a factor (download bandwidth, media size, installation duration, and - on the developer side - mastering, archieving uploading install media). All interna aside, it is perceived as a runtime of 200MB which is still an adoption stopper. How sould i respond to my boss when he says "200MB?  Can't we just use the old one?" Why does such a thing happen? With all the work going into .NET and its strategic position, how can such a simple factor be ignored? I don't blame, I just wonder.

  • Anonymous
    February 09, 2009
    Hi Peterchen - There is a more detailed explanation of the packaging for the .NET Framework 3.5 on Scott Hanselman's blog, so I'd suggest using that to help respond to your boss' questions.  I posted a few links that would be useful for this type of question at http://blogs.msdn.com/astebner/archive/2008/12/23/9250918.aspx. This type of issue is definitely not being ignored - there has been a ton of feedback and work is being done in the .NET Framework 4.0 timeframe based on that feedback.  Also, the .NET Framework 3.5 client profile that was released around the time of VS 2008 SP1 and the .NET Framework 3.5 SP1 was a result of some of that feedback as well.