I believe installing 3.5 gets you 2.0 and 3.0 as well.

Cool. I want to thank everyone for the help.

Does anyone know how much hard disk space I can
expect this to eat up?

No idea. 500MB - 750MB maybe?

Seriously? Java suffers very heavily from jar dependency issues, as it has no equivalent of the global assembly cache, meaning you get the same version of the same jar in about 10 places, and if someone's not planned ahead, you get some components needing v1, others needing v1.1, so you end up with this silly situation where the version numbers need to be appended to file names. With .NET you can just stick both in the GAC, and each can be targetted independently.

As for the different runtimes. With the exception of some very specific and unusual edge cases, if you have compiled an application for 2.0, you can be sure it will run on 3.0 and 3.5. The reason being that 3.0 and 3.5 didn't actually change the underlying runtime, they just provided enhancements to the IDE to allow simpler ways of achieving certain results (take a look at how .NET 3 implements a closure by inspecting the compiled code, it generates a lot of .NET 2 code on your behalf). The other thing 3 and 3.5 provided were additional libraries and tools to use. However the final dlls that were compiled looked as though they were .NET 2.

At some point you need new underlying features in your runtime. .NET 2 runtime was getting on in age, and so they released .NET 4 with a new underlying runtime. Once again I don't know of any specific breaking changes by upgrading, the problem is that it can get complicated unless all of your dependencies have also upgraded. I think code will port across to .NET 4 very easily, however because the runtime is interpretting the compiled code differently, it does require re-compilation to actually use the new framework.

At work at the moment, we have some .NET 4 projects calling into .NET 3.5 libraries, and apart from a customer requirement to be able to run without .NET 4, the only thing required for a total upgrade of most of the projects is changing the value of a drop down list in visual studio.

So as you might have guessed, I totally disagree with your statement. .NET 4 migration is relatively painless, and is a necessary evil in order for the language to advance. When Java finally introduce a new language level feature (Java 8 in 2013), it will probably require similar compromises. Right now Java is only appearing easy to use because Oracle have smothered the runtime and stalled releasing new language features.
Hard to tell for sure, as I have developer features installed, but it looks like 200 - 300MB.

Not true. The .NET framework uses really funky versioning.

Version 1.1 is version 1.1
Version 2.0 through 3.5 is version 2.0
Version 4.0 is version 4.0

Thus, if you have something that requires .NET 2.0, you need to install version 3.5. Blame Microsoft.

No, if you have something that requires .NET 2.0, you can install anything between .NET 2.0 and .NET 3.5, and it will work. It's true you cannot install .NET 4 to get it working, but windows update should install these both independently.

Apps are distributed with all their library dependencies in almost all cases. It's never on the user to go get a jar (or shouldn't be). I'm talking about the underlying runtime, anyway, and that has nothing to do with the libs (and it's not like hunting down an obscure dll is any easier in some cases). With new runtimes you can still run code that's older than fuck.

You're mistaking the difference between needing an upgraded runtime to support newer byte code and the lack of backwards compatibility. It's the latter case where MS has fallen down. No one thinks there's some sort of magic voodoo to get new features to work on an old runtime.

And finally, you seem to be looking at this from a developer's perspective, in which case I have one term for you: Maven. There is absolutely no superior way to manage projects and unfortunately the efforts to port this to .NET have gone poorly so far (I don't know why, I'd actually think the entire .NET world would be demanding this by now).

So yes, MS' .NET runtimes are more fragmented, you can take the newest JRE and still run code compiled a very long time ago, if you somehow must.

That's not always the case and I don't think that can be the case for any language. Newer JRE versions can fix and/or change things that older code might have relied upon or worked around, whether the developer knew it or not. You cannot guarantee that Java code written for Java 1.0 will work as intended using the Java 7 JRE. It is up to developer to ensure the code works against newer versions.


But yes, I agree that .NET 4.0 should be automatically handling all previous versions of the framework.

Java 1.0 might be an exception, but 1.1 or 1.2 code will work, afaik. A lot of folks still use 1.4 compiled code. Now, if any code was calling the restricted Sun classes directly, then yes, it might be utterly broken. There's also some other edge cases, such as the name of a JAXB class having been changed between 1.5 and 1.6, if the 1.5 code was using the optional JAXB library (JAXB is not included in the core JRE).

The point being that there is almost no backwards compat for even the simplest programs in the .NET runtime. Possibly there is a very good reason for this (though I'm not aware of it if there is), however the end result doesn't end up sucking any less. You can employ a library produced in 2005 or so in your Java app on a new JRE, you cannot do that with .NET, and I'm not sure you shouldn't be able to.

I don't know, I've never experienced such an issue between .NET 2.0 and 3.5, but then I don't run many 2.0 apps either. They should work unless the developer added a check to the installer or to the game itself see if v2.0.50727 is installed and messed it that check. My guess is that this is the problem the OP has, but I'm not sure.

You can do this in .NET. At work we use .NET 3.5 libraries in a .NET 4 app.

EDIT: It's all about the entry point. If the app that starts is .NET 4, then all the other stuff is fine. It's only if your app is compiled to target .NET 3.5 that you need it installed separately.

So, does this mean folks are putting restrictions on their applications that shouldn't be there? Why all the issues if new .NET runtimes will actually run the old compiled code?

As I said, it's about the entry point. Basically there are 3 totally independant runtimes that don't talk to each other at all. So if you start a .NET 4 app, you're in .NET 4 land, and all the code will be interpretted using that runtime. However you'd need to have an .exe that was compiled for .NET 4. If the exe is compiled for .NET 2 (or 3 or 3.5, all the same runtime), then you're using that runtime, and there is no way of escalating it to the .NET 4 one (same for .NET 1.1 to .NET 2).

So the restriction comes because of what's hosting the libraries, rather than the libraries themselves.

EDIT: To use a more concrete example. The GOG downloader is compiled to target .NET 3.5. They would only need to change a setting in the project, and it would use .NET 4 instead. At this point you wouldn't need 3.5 installed. However you would instead need 4 installed. There can be some compatibility issues, though they are few.

While you may be technically correct (were there really not a single change to the object hierarchy between 2.0 and 3.5?), I'd still recommend installing the latest version of the 2.0 framework, which would be version 3.5.
While that may be true, you would end up with code using deprecated methods. The handling of config files, for example, has been changed substantially from 3.5 to 4.0.

Also, it has been my experience that Visual Studio is quite moronic about changing the target of an existing project. You will still need to manually change the targets of all references included in the project, as they will still be pointing to the 3.5 versions of the DLLs. At least, that's what I experienced last week when I tried to do exactly that.