How many developers on the same virtualized Windows Microsoft machine?

Question

How many c# developers on the same virtualized Microsoft Windows edition is it sensible to have?

If everyone uses their own documents and settings folder, should I expect it should be fine?

Only Windows Server allows concurrent users if this option is enabled; How many concurrent users do you get out of the box?

• gnat: Sharing your research helps everyone. Tell us what you've tried and why it didn’t meet your needs. This demonstrates that you’ve taken the time to try to help yourself, it saves us from reiterating obvious answers, and most of all it helps you get a more specific and relevant answer. Also see How to Ask
• Sean McSomething: I don't know but Visual Studio is not known for being a 'light' program. Compiling large projects can put a big load on a single user system. I wouldn't want to share a computer with somebody else when I have to do it. What are you trying to accomplish by doing this?
• Phoshi: On one machine? You could have many on a box with a couple of Xeons, 256GB RAM, and a few terabytes of SSDs in RAID. You may not even want one on a box with an old C2D, 1GB RAM, and an old 80GB 5400rpm drive you found propping up the coffee table. This completely depends on your hardware.
• Makach: @Phoshi on one virtual machine yes. I know 1dev->1win->virtualized is fine, but what I've been proposed is n*dev->1win->virtualized
• MSalters: Why? What is the benefit you expect to achieve? Developers are a lot more expensive than hardware; slowing them down even a bit is costly. It's not the 1970s anymore.

Answer 1

One. For several reasons:

1. Windows has lots of aspects that don't mesh well with multi-user use, especially concurrent use. Multiple user profiles and remote access are really only part of the answer, and a fair amount of the answer hasn't been done yet.

2. For C#, you'll be using Visual Studio, which is a heavyweight application. Our experience is that even with only one user, a virtualized VS machine is noticeably slower than the user wants it to be.

3. Depending on the application(s) you're developing, you may have problems isolating the users work from each other. For example, if you're building web services or a website, you'll need to keep user A from accidentally executing against user B's services.

4. As Phoshi implies in his comment, to serve multiple users well, you're probably going to spend at least as much on high-end hardware as you would going the non-shared route.

• Alan B: In terms of application development I would agree with most of that (apart from 1), especially if Windows services, web services are involved.