Windows is not a .NET Framework delivery channel either

We learned a while ago that Windows is not an MFC delivery channel. And, since you asked, it's not a .NET Framework delivery channel either.

If you're developing a program that uses the .NET Framework, you have to have a backup plan if the version of the .NET Framework you need is not installed on the computer. This might mean including a copy of the installer on your CD. It might mean redirecting the user to an appropriate download site. It might just mean telling the user, "This program requires version XYZ of the .NET Framework." Whatever you do, you need to do something.

Windows XP didn't come with any version of the .NET Framework. Windows Vista came with version 2, and Windows 7 came with version 3.5, but these were provided as optional components which were installed by default. You can go into the Programs and Features control panel to remove them.

As I recall, the application compatibility folks have a list of programs that treated Windows as a .NET Framework delivery channel; if you install any of them, and the version of the .NET Framework they depend on isn't installed, the application compatibility layer will display the informational message that the application neglected to.

Bonus chatter: These programs which treated Windows as a .NET Framework delivery channel may have been misled by charts like this one or lists like this one which give the impression that Windows is a .NET Framework delivery channel.

Comments (52)
  1. Adam Rosenfield says:

    Is there a similar compatibility shim for DirectX?  It wouldn't surprise me at all if there were lots of programs that assumed DirectX was always installed.

  2. Alex Grigoriev says:


    There were also programs that wanted to instal some freaking obsolete DirectX version no matter what.

  3. RichB says:

    But it is a VB6, VBScript and JScript delivery channel and used to be a Java delivery channel.

  4. Joshua Ganes says:

    The compatibility team is stuck in a lose/lose situation. They must add this sort of functionality in order to ensure compatibility. Doing this, however, just encourages future developers to continue to be sloppy. "No need to pay attention to prerequisites — Microsoft will do that for us". It must be depressing to work on the compatibility team :(

  5. Stuck in the 90s says:

    What's a CD?

  6. Michael Kohne says:

    @Stuart – I expect that they don't promise to bake .NET into the OS because .NET changes a LOT faster than the OS does! So if you're going to have to get everyone to upgrade anyway, why worry about baking it in?

    Also, it should be noted that XP (which existed before .NET) is STILL in wide use around the world (mostly because it works just fine for a lot of what people want to do).

  7. Robert says:

    Well, at least Windows Update is a .NET delivery channel. Now we just need broadband everywhere.

  8. Adam Rosenfield says:

    @Stuart: Because it's a slippery slope.  If .NET gets included with the OS, then people would instead be griping about some other SDK/platform/what-have-you that's an optional component.  Then people start complaining that Windows is so bloated, it comes with these 400 different DLLs I don't need.  Oh wait, they already do that.

  9. -Sander1981- says:

    By the way: it is perfectly possible (and not too hard) to create an installer that checks for the required .NET version (and other prerequisites), and downloads it if missing. That way you do not have to create a huge installer or multiple versions for people who already have the .NET framework.

  10. Philip says:

    It's the worst of all worlds to ship a .NET Framework version with Windows and then have it be an optional (but default) component: Application developers can't rely on it being installed (it's optional!), but Microsoft has to service it with updates as part of the OS (it is after all part of the OS install, even if optional).

    My guess as to why it's not just always installed? Secure computing initiative. It's optional so you can choose to not install it and thus reduce your attack surface. However, since only major corporations (and computer geeks) would ever bother practically everybody does have it installed anyway.

    The end result is that we can't rely on it being installed, Microsoft still has to treat it as being part of the OS with all the support commitments that entails, and (almost) everybody still has the same exposure to any critical .NET flaws that might be uncovered.

  11. Dave says:

    It seems strange to think that the .NET Framework isn't really part of Windows, given that Microsoft has been pushing it hard for a decade. At least Microsoft Update will recommend new versions, although not that insistently. Marc Lucovsky summarized the problem in his blog "Shipping Software" back in 2005 (Bing for it).

  12. Joshua says:

    The reason is the sales documentation made the claim that .NET was part of Windows Vista.

    I've learned the hard way that anything sales says is not to be trusted. Windows XP 32 bit only supporting 4GB RAM is not a limitation of the hardware. And they still told that lie with Vista despite the fact that Windows Server 2003 EE 32 bit already had support for more than 4GB.

  13. Daniel says:

    Isn't this something the package manager should deal with? Seems pretty archaic to manage one's own dependencies.

  14. James Strain says:

    Microsoft gets heckled for shipping IE and Media Player with Windows from vendors of similar apps. If they ship .NET as a core OS component, I guarantee some other company would start complaining of anti-competitive practises.

  15. Bart says:

    Talk to the windows update people. They seem to think that new .NET runtimes are pretty high priority updates and that makes me think that Windows IS a .NET delivery channel. As is the "bing toolbar" by the way. Dilluting the "important" in "important windows updates" is not a good idea. But I digress…

  16. Eugene says:

    Seems, that Microsoft want to discard .NET framework.

    Its time to start learning of Object-C.

  17. sukru says:

    The normal thing to do is to test your program's installer on a clean Windows setup. This even goes for the development environment. All of a sudden you realize your Visual Studio solution has dependencies for the packages installed on the local machine, and will not build on another one.

    This also goes for Office (+ its fonts) as well.

  18. John says:

    So does Windows ship with any .NET applications?  If so, are the dependencies managed correctly?

    [See the linked article, just mentally substitute ".NET" for "MFC". -Raymond]
  19. Robert says:

    Windows XP 32 bit only supporting 4GB RAM is not a limitation of the hardware.

    No, it's a limitation of the drivers. They have to be compatible with PAE. If the aren't, the system bluescreens. You can do that for the server platform with its more limited install base, specialized hardware and (normally) support contracts. You don't want that on the clients. "Hey, I just installed 8 GB of RAM and now my system doesn't boot anymore! Windows suxx!"

  20. gkdada says:

    I ran across the opposite of this, the other day. An application insisted that it HAD to have .NET framework 1.1, before it even installed. It didn't matter to this application that I had .NET Framework 4 installed. (Aren't the frameworks backward compatible?)

  21. Joshua says:

    @Robert: You know that, I know that, but that's not what the website says.

  22. Logan says:

    Don't forget, server SKU's also don't come with .net enabled by default.

  23. strange says:

    i would have thought it prudent to supply .NET Framework 4.0 with Windows XP in the first place, would have avoided all these problems. Oh well I suppose we can't go back in time and fix it now.

  24. dasuxullebt says:

    I had the impression that .NET was always advertised to be the "new" WinAPI (with the bonus that it can partially be run under free reimplementations like Mono). To be honest, the only time I used .NET so far was trying vb.NET on a Linux-Machine, so in fact I do not know much about it, but as I had that impression, maybe many other people that do not know much about it have it, too?

  25. glonq says:

    @Dave, I bing'd for 'Marc Lucovsky Shipping Software' and found a link to his blog but not that specific posting.  Google'd and got a link directly to that posting from 2005.  Plz stop recommending the wrong search engine ;)

    And just to keep this on-topic, I wish that I could rely on .net and silverlight always being there.  I'm currently trying to convince a small potential customer to allow silverlight on their PC's so that they can run our app.

  26. Adam Rosenfield says:

    @glonq: While Google is my personal search engine of choice, in this case you're flat out wrong.  A Bing search for 'Marc Lucovsky Shipping Software' (sans quotation marks) gives the blog post as the first hit, whileas the equivalent Google search gives it as the second hit; both search engines also note the misspelling and search for Mark instead of Marc.

  27. Bruce Cran says:

    @sukru: that wouldn't be enough on modern versions of Windows, since the .NET Framework is installed by default but can be removed.

  28. ErikF says:

    Really, how's this any different from Web designers who rely on Flash/Silverlight/Java?  It doesn't matter what component is missing; developers should assume that components are missing and have some sort of method for the end user to install those components, or have a workaround for the lack of an optional one.  Anything less is just laziness on the part of the developers (particularly since the installers that come with Visual Studio already look for dependencies and allow you to add those redistributables to the MSI package!)

  29. Robert says:

    Well, web designers have the advantage of browsers solving that problem for them.

  30. Stuart says:

    I'm actually interested in whether you have any inside knowledge on the reason *why* the decision was made to not make Windows a .NET framework delivery channel – or whether you can make one of those inspired psychic guesses on the question.

    Not making .NET a built in Windows component has several obvious consequences: .NET developers have to take extra steps to ensure the framework is present, adding to the costs of choosing .NET as your development platform; Microsoft developers working on Windows itself cannot do their development on .NET; and so on.

    I'm a .NET developer because I feel that those extra costs are worth bearing. But obviously Microsoft, as an organization, feels that .NET is a platform that offers some compelling features to developers. They think it's worth putting some large amount of effort into creating and promoting this development platform. Why *not* make it a built in OS component so that you can (a) aid with the promotion of the platform by reducing the costs external developers have to bear when choosing to develop on it, and (b) make those advantages available to your own internal OS developers also?

  31. James Day says:

    Stuart, your convenience as a developer is not sufficient reason to inconvenience all other Windows users by making them have larger install images and larger backup disk images for junk that they never use. Junk not referring only to .NET but to whatever arbitrary things might be installed on the off chance that they could be used by something the user/console/embedded application server might install someday. Junk isn't an opinion on whether .NET actually is junk, just that it certainly is to those who don't use anything that needs it.

    It also broadens the attack area and introduces risks with respect to competition regulators that might dislike favouring one toolset over another.

  32. Erwyn van der Meer says:

    Some versions of Windows *are* a delivery channel for the .NET Framework. In fact the version 3.5.1 included in Windows 7 can only be installed as a Windows feature. You cannot install the .NET Framework 3.5 SP1 redistributable on Windows 7 (and 2008 R2). Also the .exe hotfixes for .NET Framework 3.5 SP1 cannot be installed on 3.5.1. You need the Windows Update mechanism via .msu to do that. And to top it of .NET 3.5.1 is compiled in a separate branch for Windows. It means some hotfixes that were developed for .NET 3.5 SP1 were not even automatically available for 3.5.1 since the fixes were yet to be merged into the Windows branch and to be compiled and tested.

  33. Susan says:

    "You can go into the Programs and Features control panel to remove them. "

    Go try it please.  Betcha it doesn't work in all versions.  Let me introduce you to Aaron Stebner of Microsoft:…/mailbag-what-version-of-the-net-framework-is-included-in-what-version-of-the-os.aspx

  34. ivan.danilov says:


    No, they are not. Versions of .NET framework could live on your computer side-by-side perfectly. To be precise, there're 3 crucially different versions in general:

    * .NET 1.1

    * .NET 2.0 (3.0 and 3.5 are just packs of libraries on top of 2.0)

    * .NET 4.0

    So if you have only 4.0 – it can't help the program which depends on 1.1 – you should install 1.1. Or search for newer version of course :)

  35. Bailey's says:

    Raymond, when you read a comment that says "you're probably wrong" and introduces you to an article you linked to yourself, does it evoke a facial expression? If so, could you describe it?

  36. S says:

    This is why I always select "Stand Alone EXE" when I compile in QuickBasic 4.5

  37. Troll says:

    If it's not a deliverable, then like Erwyn van der Meer said, it should include the MSI-based version. A single update should install on whatever OS the .NET Framework supports. MSI is the best and most robust installer technology Microsoft has created and MSU is the worst and most bloated disk eating crash-pone unreliable slow I/O intensive update installer technology Microsoft has ever created.

  38. Medinoc says:

    What is the recommended method of testing whether a given version of the .Net Framework is installed?

  39. Cheong says:

    @Medinoc: Create a Setup project, I think…

    Regarding .NET framework versions that come with OSs, I think WinXP SP1 come with .NET Framework v1.0 runtime installed by default. My PC has this version of runtime installed but I don't think I ever installed anything that needs .NET v1.0.

  40. Brian Reiter says:

    I'm having trouble following the logic here. .NET Framework 2.0 ships with Windows 7 and Windows Server 2008 R2 as a mandatory component that cannot be uninstalled. Only the .NET 3.5.1 library components are optional. Only Server Core makes .NET 2.0 optional. It seems like the key technology that depends on .NET 2.0 is Windows PowerShell which is itself a mandatory system component of NT 6.2 (except Server Core where it is optional). It's also my understanding that other mandatory components like the Win7 troubleshooters are themselves dependent on PowerShell.

    I get that if these dependencies did not exist, then Windows wouldn't need to ship .NET 2.0 to work but it does. Windows 7 is a ship vehicle for .NET 2.0. That's just a fact. It may be  a true statement that there is no guarantee that .NET 2.0 will exist in all future versions of Windows but it seems distinctly unlikely that future versions of Windows will not ship a mandatory version of .NET for the foreseeable future unless and until Microsoft has some form of static linking for .NET or starts shipping a private .NET runtime to service system components the way that Windows has its own private C runtime library.

    [I think you're confusing "Windows includes X" with "Windows is a delivery vehicle for X." One is how things happen to be (e.g., because of internal dependencies). The other is a contract. I thought I made this clear in the article itself. (And notice how the .NET Framework version keeps changing, so even with your definition, given the current evidence, it's clear that the statement "Windows is a delivery vehicle for .NET Framework version 1.1" is false.) -Raymond]
  41. Brian says:



    While what Ivan says is true, but it is possible to run older .Net apps under newer versions of the framework via an application config file.  This is not the default behavior and might cause unexpected behavior if the app relies on an idiosyncrasy specific to the older version of the framework/

  42. Paul M. Parks says:

    @Susan, do you realize that the link you gave is already in Raymond's original text?

    "…may have been misled by charts like this one or lists like this one …."

  43. Alex Grigoriev says:

    "MSI is the best and most robust installer technology Microsoft has created". Though the msiexe.exe programmers have never learned to use WaitFor functions instead of polling in a tight loop. I suspect this is why msiexec basically takes the whole processor. Watch for the CPU fan to spin up; happens always.

  44. Simon Robinson says:

    It would help if the Visual Studio 2010 setup project type was bug free. Supposedly, you can create a setup project in VS, which will handle installing your app on a client's machine, including installing the correct version of the .NET Framework from if necessary. Unfortunately, I've found it sometimes goes off and downloads the .NET 4.0 client framework when your app actually requires the full .NET 4.0 framework. Gives very nasty runtime errors on the client's machine!  (Luckily in my case, the features my app used that wouldn't work with only the client framework were minor and easily replaceable, so in the end I was able to just remove them).

  45. Jeremy Drake says:

    I wonder how this blog post might have been different if the "Windows .NET Server" name stuck?  With .NET right there in the name, it'd be hard to argue that it doesn't actually promise to deliver .NET.  Thank God somebody at Microsoft saw the light, and we didn't have to find out…

  46. kinokijuf says:

    @Ivan Danilov: there was .NET 1.0, but it was extremely buggy and I saw no apps for it. Also, the only placre where I could find Polish version was an old XP SP1 cd.

  47. Anton says:

    Why any framework (mfc, net, java – doesnt matter) deadly needs to be a component of windows?

    What is so special in "generic Net application" that it cannot simply run?

    Somebody stop unmanageable hell. Design for portability already. Link frameworks statically.

  48. Brian Reiter says:

    @Raymond: "I think you're confusing "Windows includes X" with "Windows is a delivery vehicle for X." One is how things happen to be (e.g., because of internal dependencies). The other is a contract. I thought I made this clear in the article itself."

    I must have missed where you defined "delivery vehicle/channel" to be a contract. That's an idiosyncratic usage on your part. I read it to simply mean the method by which your product is delivered to consumers. Honestly, I'm not at all sure we are speaking the same language and maybe this is an example of "Microspeak".

    It's not at all clear to me that there is a meaningful difference between "Windows includes X" and "Windows is a delivery vehicle/channel for X". On the face of it, the latter formulation is simply a more abstruse construction of the former.

    I understand that you are saying installer developers need to take ownership of their dependencies but I'm afraid that point is being obliterated by the cognitive dissonance of arguing an obscure point of reasoning that somehow Windows is not a vehicle by which Microsoft ships .NET to customers when it clearly is.

    [To me, a "delivery vehicle for X" is "a thing which is contractually obligated to provide X". As we saw with this and other examples, some things come with Windows not because Windows is a delivery vehicle contractually-obligated provider for them but because Windows itself uses them internally. (In a sense, Windows is following its own guidance: If you need X, then install X. Don't assume somebody else will install it for you.) -Raymond]
  49. Voo says:

    @Anton: So your solution to every security problem the framework fixes (and there will be more than enough) will be to sell/make available a new version of your program? Even if I believed you (and I really don't) updating dozens of programs that use the framework instead of just the framework sounds somehow a lot more work.

    Memory or space concerns may not be especially important in this day and age, but security sure is.

    [Indeed, this nightmare scenario has already occurred. "Q: If I use third-party applications that distribute the gdiplus.dll file, could I still be vulnerable even after I have installed all required Microsoft security updates? A: Yes." -Raymond]
  50. nobugz says:

    Mistake in the post, Vista has .NET 3.0 pre-installed.  Win7 has 3.5 SP1.

  51. nobugz says:

    Oops, realized I missed the point after checking the links.  Sorry.

  52. glonq says:

    @adam, bing didn't get it (as described) when I tested it.  If it worked for you subsequently, then chalk that up to that whole "bing steals google results to improve itself" debacle that occurred a few weeks ago.

Comments are closed.

Skip to main content