The answers that say that this has to do with RAM are deeply wrong. It is important to correctly understand the relationship between disk space, RAM and address space.
Here's how it really works.
Each process on 32 bit Windows is given a 4 GB address space.
Of that 4 GB address space, 2 GB is reserved for the use of the operating system and the other 2 GB is available for the user code in the process to use as it sees fit.
Now let me be extremely clear on this point: address space is not memory. A process can have as much memory as it wants. I'll say it again: a process can have way more than 4 GB of memory allocated. The limit is that only 2 GB of that memory can be mapped into the user-mode address space at any time.
I haven't mentioned RAM because RAM is irrelevant to the question of address space. It doesn't matter whether the operating system is storing the memory of the process in RAM or on disk or whatever. RAM is just a performance optimization that lets the operating system store the memory in a fast chip rather than a slow disk.
Your process tells the operating system how much memory it wants, and where to map that memory into the 2 GB address space. If the process needs more than 2 GB of memory then it will be unable to map it all into address space; such a process either needs to be cleverly written to tell the operating system which pages of memory to map and unmap from address space, or use less memory. If it does not then it will fail with an out-of-memory exception.
Perhaps an analogy would help. Your building has a parking lot with a hundred spaces. That's RAM. You have a parking garage down the street with ten thousand spaces in it. That's disk. You and everyone else in the building each has a keyring with room for ten keys on it. That's per-process address space. Does the fact that you only have room for ten keys mean that you can own only ten cars? No! You can own as many cars as you want, but if you want to access eleven of those cars, you're going to have to take one of the keys off the keyring, store it somewhere else, and put the new key on the keyring. That's mapping memory into and out of address space.
What if everyone in the building each tries to park ten cars in RAM? If the parking lot gets full then they'll have to swap some of those cars to the parking garage down the street. Does that stop them from having keys on their keyrings? No, obviously not. It just makes it slow when they want to drive a car that is parked out on disk.
What if there was a valet service that figured out which cars people were more likely to use, and moved the less-used ones to the parking garage down the street? That's the memory manager putting less-recently-used memory pages into the swap file.
You point out that you have a big disk. Suppose you have a 10 GB file on that disk. You can certainly use the contents of that file in your .NET program, but you can't have it all loaded into contiguous address space at once. You have to read it in chunks. If you were clever you could map it into process memory all at once -- you've got plenty of memory -- but you couldn't then map 10 GB of memory into 2 GB of address space.
In general it is easier to not try to get that much memory in the first place; just read it in a few hundred KB at a time.
It is extremely common for people to confuse address space with physical memory, but they have not been the same thing for decades. For more details, see my article on this subject, “Out Of Memory” Does Not Refer to Physical Memory.
