[gisenberg]

I think it's less about not wanting to use Visual Studio and more about not wanting to have a Windows VM thrashing resources. I've worked with teams that have migrated to ServiceStack just to avoid running Windows.

Assuming that running Windows is a non-issue, the parts that really, really bug me are:

   - Background operations suddenly become foreground operations that stall the IDE with a dialog saying "A background operation is taking too long."
   - Misclicks spinning off long background tasks that stall the IDE. 
   - Automatic refactoring/code analysis that will stall the IDE.
   - Incredibly aggressive automatic reformatting.
   - The Microsoft Account agenda. VS2013 wants me to sign-in with my Microsoft account on so many different occasions: settings sync, Azure, Windows Developer account registration, auth refresh, etc... which wouldn't be so bad, but I'm signed in via Windows 8 already, adding insult to injury.

[jasallen]

- 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 ...

[gisenberg]

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.

[codelap]

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.

[gisenberg]

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.

[codelap]

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.

[gisenberg]

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.

[ryanmolden]

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)

[gisenberg]

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!

[crankpot]

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.

[codelap]

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

[githulhu]

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.

[gisenberg]

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.

[codelap]

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.

[sixothree]

I believe you have an install issue.

[gisenberg]

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.

[alkonaut]

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).

[gisenberg]

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.

[alkonaut]

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.

[ryanackley]

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.