Build Your Own Arcade Controls Forum
Main => Software Forum => Topic started by: Gray_Area on December 13, 2010, 08:10:50 pm
-
I know the standard statement, 'any programs requiring .net won't function/they may alert you you need .net.' In using tinyXP 11, I have had no need of .net until trying out CCS64 (which I'm not keeping anyways...). So, in general and popular emu uses, what require .net?
-
Just install it. All it does is take up space on the HDD. It's not like it runs in the background all the time or anything so it's not going to effect the performance of your PC.
-
If software makes use of classes/functions from the .NET library you need to install the framework on your PC for the code to run correctly. Same goes for example for Java, Flash etc.
Wikipedia -> The Microsoft .NET Framework is a software framework for Microsoft Windows operating systems. It includes a large library, and it supports several programming languages which allows language interoperability (each language can utilize code written in other languages.) The .NET library is available to all the programming languages that .NET supports.
-
+1
Just installing the .net framework won't actually leave anything "running" or even setup to run on your machine. Only when you fire up a program that was compiled with .net will the framework load up, so there's no worries of "taking up resources" and such, other than just some harddisk space, just like headkaze said.
-
Coming back to this: for a fresh install of XP32, which or what versions of .net do I need?
-
You don't need any version for a fresh install of windows. When you want to use software that depends on some version of the .net framework, then you will need to install that version. So you could either not install any .net frameworks until you need them, or install them all so they're there and ready to go if/when you need them. Personally I install them all, but I do some of my programming in C# and I'm not a strict minimalist anyway.
-
You don't need any version for a fresh install of windows. When you want to use software that depends on some version of the .net framework, then you will need to install that version. So you could either not install any .net frameworks until you need them, or install them all so they're there and ready to go if/when you need them. Personally I install them all, but I do some of my programming in C# and I'm not a strict minimalist anyway.
I asked because it wasn't clear to me about whether later versions superceded earlier ones, and whether version 4 would be even applicable to anything I might run on XP32 and older hardware.
-
.net 1.0 is a standalone "thing"
.net 2.0, 3.0, and 3.5, are all slight improvements over each one. They can coexist on a machine with 1.0, or 4.0, but they effectively replace each other when installed.
.net 4.0 is another standalone thing, latest version, can be installed side by side with 2/3, and 1.
A .net application is marked to require a particular version of the runtime, so if you need to run a .net 1.0 program, you'll need the 1.0 runtime, etc. Not many apps use the 1.0 runtime.
Usually, you'll be good installing 3.5 and 4.0. If you install 3.5 you should automatically get 2.0 and 3.0
-
Just a side note, my ControllerRemap and Engine18 for Mala require .net 3.5, though Mala itself DOES NOT require .net.
-
How about a bit of a history lesson?
Prior to .net capable versions of visual studio, each and every programming language had it's own "runtime files." This is quite similar to .net except that the files for C+ applications were different than vb and ect... .net was designed to help remove all of this bloat by offering a common, cross-langauge rumtime package. It didn't really work. That being said, if you have an app that needs .net install it, otherwise ignore it.
-
How did it "not work"? They are constantly expanding the language (I think .NET 4 is the latest) so the runtimes update. It's the same with C++. I can't remember if the .NET 4 redist includes the older .NET versions or not though but if it doesn't just install the latest.
-
It didn't work in that .net was supposed to pretty much eliminate the need for most other libraries. And yet many .net apps also need visual c runtimes or whatever because people are choosing to use the non m$ languages and then tacking on .net or .net doesn't have all the functionality they need. It was also intended to eliminate bloat, but we know it didn't do that either. ;)
-
It certainly didn't eliminate bloat, but I'm not sure that was actually ever a design goal.
Providing a single consistent managed platform for JIT compilation to a variety of hardware devices, and a fairly robust set of libraries out of the box was (you'd almost never eliminate the need for other libraries, heck, I'd definitely make use of the libraries for the LEDWiz rather than write my own).
It sucks to have to deal with runtimes, I agree. I much prefer a single exe distributable, but, hey, even C has runtimes. Granted, they usually already exist on the machine, but then, .net runtimes are included with Windows (maybe not the absolute latest revs, but that's understandable).
-
Actually .net generally isn't included with an OS and if it is, it's 1.0 (which nearly nothing uses at this point). Now it appears that windows comes with the latest version because it is downloaded by windows update, but the fact remains that just like in the VS 6.0 and below days, you still have to make sure that your user has access to .net even though they probably should already have it.
So it basically hasn't changed anything... which is what I was trying to say.
We are getting off topic anyway, none of this really matters.
-
Wasn't it also supposed to alleviate the old 'dll hell'?
-
Right, it does, mostly.
Generally speaking you don't "register" .net dlls like you used to with COM dlls. Just put the app EXE and all the DLLs it needs in one folder and the .net runtime can find them.
Of course, there's plenty of exceptions to that rule, but for the most part, that's how it works.
-
Right, it does, mostly.
Generally speaking you don't "register" .net dlls like you used to with COM dlls. Just put the app EXE and all the DLLs it needs in one folder and the .net runtime can find them.
Of course, there's plenty of exceptions to that rule, but for the most part, that's how it works.
That's an OS thing, not a .net thing. I can put a vb6 or vc6 dll in the same folder as an exe and as long as the pc is running win xp or higher, it will automatically register.
-
I still write dll's in VC6 just to reduce the need for runtimes. AFAIK XP includes them because I've never had a user need to. .NET has nothing to with reducing the need for dependancies though. It's a managed language that is JIT compiled. Just like C++ it requires its own runtimes.