- Never had background to foreground stall IDE issue in VS2010 or up

- Nor misclicks stall IDE

- Nor automatic refactoring analysis stall IDE

- Automatic reformatting is a once click option to disable and is not terribly aggressive in VS 2010 up.

- wants you to. Not forces. So, by the way, do JetBrains, NetBeans, Oracle ...

Not running into those issues must be really great for you, but does very little to make the experience better for me. I tend to run VS under virtualization with TFS, which is far from a pleasant experience, even on modern hardware.

So on a local machine, in virtualization, you are running an IDE, SharePoint Server, SQL Server, IIS, TFS. If you aren't running it from a separate SSD drive then the problem has nothing to do with the IDE. You have an IO bottleneck.

I'm not sure where you pulled SharePoint and SQL Server from, and running the TFS client is a far cry from running the TFS server.

That said, my experiences with Visual Studio only serve to underscore the point that my peers would prefer to avoid running a Windows VM altogether if there are open-source alternatives that are good enough.

From your comment, you said TFS. TFS is the server, which include SqlServer, Sharepoint, an OLAP cube, and the TFS server components. The TFS client extension, (which is not TFS) has been baked in for the last 2 versions. So I assume you're using VS 2010, and that is a much different beast. It has a lot more issues, but it's a much improved IDE.

As far as virtualization, why are you working in a virtual environment? What are your machine specs? What is the emulator? I'm genuinely curious, because I haven't encountered any of those issues.

I was referring to Team Explorer which, as of VS2013, doesn't appear to be included out-of-box. Apologies for the confusion.

Virtualization is kind of a red herring here, because as mentioned before, this happens on an array of workstation-level hardware (quad-core Xeon/i7, 16-32GB configurations, SSD).

The point is that virtualization makes these already-painful existing issues much more pronounced, such that my peers actively want to avoid spinning up a Windows VM for a project. These experiences, whether agreed with or not, were largely responsible for the immediate revulsion my team felt to Windows-based solutions. I can't begin to explain how excited people were at the prospect of not having to use Visual Studio anymore when ServiceStack rolled out at my prior company.

My use case for virtualization is mobile development spanning iOS, Android, Windows 8 and Azure-backed services. The last few companies I've been on-site at outfit their employees with high-end MacBooks, with developers occasionally using virtualized Windows under protest.

Team Explorer has been baked in for the last two versions. Regardless, most of your points have little to do with Visual Studio, and a lot to do with Windows and Virtualization. Besides, half your gripes can be turned off in the settings.

If you have to work with the tools daily, then take the time to learn them. You'll thank yourself.

I'm not sure if you're intentionally glossing over the "this happens with or without virtualization" point, but I'm glad you're happy with the tools you're using.

Far and away the biggest problem with the background/foreground issues is COM and its apartment models. A large part of some of the core pieces of Visual Studio are (still) written in native code and are STA bound objects (mostly when they don't really need to be, but that's another discussion).

Converting off of STA in legacy code is extremely difficult due to the transitive nature of it as well as the fact you likely have very large and complex types which were never written to be thread-safe because the STA protected them from that (let's not talk about re-entrancy though :)).

It is getting better since managed code has MTA semantics by default, but even with async code all it takes is one person calling Wait on a Task on the UI thread...

A huge sync API surface that is publicly callable also doesn't help. Even if you want to make things async under the covers you generally can't since callers are expecting synchronous semantics and there is no (good) way to make work async, present a sync calling surface to callers, and not block the UI thread (if you say nested message pump, you lose :P)

I don't imagine it to be an easy problem to solve, but it's good to hear your experience with it. Thanks for chiming in!

I work in a .NET C# environment and I get all of these issues. Sorted in order of most annoying to least annoying, they would be: #2, #1, #5, #3, #4. I don't really mind 3 and 4. I'm just saying this to affirm that your experience is not unique to you.

The most annoying issue to you, is that you click the wrong button, and it does what it's supposed to do?

Sure, but why have features that block the UI for an indeterminate period of time with no way to interrupt? You paid a lot of money and you expect the experience to be good.

Interruptions to flow are indeed high on my list of annoying issues. Blocking the UI unexpectedly to poll an external service for an indeterminate amount of time is frustrating and worthy of resolution.

Okay, for starters, you hit the wrong button. Secondly, pretty much everything is customizable, so edit your toolbars or menus to move those to a slow running menu. The others about code formatting and auto refactoring are easily disabled. Learn your tools.

I believe you have an install issue.

Wouldn't that be nice?

I'd be inclined to agree with you if it were just me or one machine, but these are characteristics that I'd use to describe Visual Studio across a number of machines, projects and teams over several years.

Use a fast machine. Do not develop in a VM. Do not use a mechanical hard drive. Have at least 8GB of ram. Absolutely do not have any kind of on-access antivirus scan enabled for project output/intermediate dirs or GAC.

I find a 100project C# solution (200mb deploy) to be perfectly snappy when using & fast to build. There are and have been zillions of annoyances with VS but perf hasn't been one since I set my machine up properly (in the office most of the developers complaining about build perf could cut 75% or more just by excluding certain dirs from AV scan).

This is great dogma for people that control their work environment, but keep in mind that not everyone has that luxury. Hardware upgrade cycles and/or upgrade budgets can prevent people from working on the hardware they'd like, group policy can prevent scoping down AV settings, job role may require frequently hopping between OSX/Windows, etc.

Well, it's fairly easy to keep developers happy. Good hardware and coffee is so cheap compared to finding new developers...

I'd be as upset by a group policy demanding I scan my VS intermediate dirs on access as I would be by a no-chairs policy at the office. It's a dealbreaker.

I've run VS2013 natively and on a Virtual Machine with no problems at all. Certainly not what you're describing.

I'm not talking amazing hardware either, just a computer I put together myself.