running number of visual studio applications

I'm not too familiar with OS and processor tasking / usage but whenever I run different programs at once; for instance 3 different applications all in visual studio a lot of memory is used. I understand that visual studio on its own uses a lot of memory and CPU power and depending on the program creates many USER objects etc.

My machine has 2GB of RAM and a 2.13 dual core CPU. The problems arise when writing to files and one program will crash when trying to access a file that is only accessible by that application, yet gets errors that it was unable to access the file.

Does this make sense? Does the number of applications running at once affect the execution? I mean, is this just probably an issue with my code or should I restrict the number of applications running at once?

The number of applications running is almost irrelevant to whether programs crash or not - that will only happen in your memory usage is very extreme (eg: 5 times your physical memory). In general the only thing it would affect is the speed.

The crash is almost certainly an issue with your code. Even if it isn't, your code should still deal with it in a graceful way rather than crashing.

Thank you for the response. I will try posting the error related concerns in the appropriate vb forum then.
So even when using mulithreads, the code will always be the issue and not memory usage? right?
Thanks again.

I get the same type error when running an SSIS package set in Studio (file in use). It is always related to memory for me (2 Gig machine but 6 gig in use) I use the package to migrate a database (it is about 20 gig in size). The error occurs at different places in the process some times when I call 1 package (Migrate 3) other time a different 1 (migrate 5) I have 10 packages that get called from one starting package.

In general, I suspect that memory usage by .NET apps is mostly a mirage. A .NET app gets a pool of memory to use, then can request more from the OS. If the OS needs to claw back some memory, or if it refuses to give the app more memory, then the .NET app can run the GC to recover memory. However, the GC is relatively slow, so I suspect that .NET apps request new memory before recovering unused memory in their own pool. This makes them appear to grow over time because the total memory allocated to that process keeps increasing, but it may not mean that the total memory USED by the app is increasing. It may just be that the app is asking for more memory rather than recovering memory from dead objects. This would have little or no real impact, but can appear alarming.

Memory use can still be a concern. This is why there is a need for things like memory profilers. Example:

http://memprofiler.com/

SSIS has its own issues:

SSIS Packages Need Love Too, er, Memory Too!