It pains me if I am honest. Our CMS is built on .NET and it's like an uphill battle selling it as it's on IIS and it's .NET. I have played around with the idea of reworking it into an open source language and open source database but I would miss Visual Studio and the language a lot.
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.
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 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.
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'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 have done a lot of Java, Scala, etc. IntelliJ & Eclipse are both wonderful IDEs in their own right. A lot of things like ReSharper were in those IDEs before Jetbrains (maker of IntelliJ) made the plugin for VS.
After trying VS for a couple of projects I found it completely baffling and backwards.
And I don't think this is because VS is bad, but because the way I approach software is completely different. I want to be able to compile things from the command-line first and use the IDE to edit the code. The way this happens makes it much harder to use other tools I like such as Jenkins. I can't ssh to a windows server.
On the other hand I can see where somebody might be frustrated that they' can't remote desktop into a linux server or had to learn a new config language instead of having a GUI.
IIS is another beast altogether. I've had to help customers set up their servers and the instructions are a set of screenshots that are hard to follow and easy to skip. Most apache/nginx configs clients can copy/paste fragments into their configs to get things working.
I could have 1000's linux servers up by lunch, but it would probably take me all day to configure one windows server. You probably have a better solution for this, but I've not come across it.
For me VS C# probably wouldn't be too bad if it didn't require running windows.
It sounds like you just don't know Windows/VS/IIS as well as you know the other stacks which is entirely understandable since I'm guessing you don't work with them very often.
For future reference you can compile VS projects from the command line if you want using MSBuild, that's all building in VS does. As far as IIS is concerned you can maintain all it's configuration via config files so an experienced Windows admin could have 1000's Windows servers up by lunch too. They'd probably take all day to get a Linux server up though.
> For future reference you can compile VS projects from the command line if you want using MSBuild, that's all building in VS does.
Err, no - MSBuild, is basically a clone of Ant, except that it is meant to be generated by Visual Studio. This is completely backwards from what happens in say Java/Scala with Maven, SBT or Gradle.
The advantage of having the build process external, as happens with Maven and Maven-like environments, is that you can easily automate things by writing plugins, plus you're not tied to the IDE at all. You need to push your artifacts into a repository? There's a plugin for that. You need to sign your artifacts with a PGP key? There's a plugin for that. You need to automatically increment the version number on releases? There's a plugin for that. Etc, etc... and all of these can be used in continuos integration processes.
Plus, MSBuild doesn't handle dependency management, which is completely retarded. You've got NuGet now, but again, Microsoft had to over-engineer it, to make it IDE friendly and thus the ease of setting up your own Maven repository is gone.
And have you tried building MSBuild projects on top of Mono? Try it. It's fun ;-)
Basically only a .NET developer that never experienced other environments could claim that MSBuild/VS.NET is satisfactory, but for the rest of us, it's like trying to do software development with early-2000 tools and IMHO, that's where the entire .NET ecosystem is.
> Err, no - MSBuild, is basically a clone of Ant, except that it is meant to be generated by Visual Studio. This is completely backwards from what happens in say Java/Scala with Maven, SBT or Gradle.
MSBuild does not require Visual Studio
> The advantage of having the build process external, as happens with Maven and Maven-like environments, is that you can easily automate things by writing plugins, plus you're not tied to the IDE at all. You need to push your artifacts into a repository? There's a plugin for that. You need to sign your artifacts with a PGP key? There's a plugin for that. You need to automatically increment the version number on releases? There's a plugin for that. Etc, etc... and all of these can be used in continuos integration processes.
The equivalent of plugins for MSBuild is Tasks
> Plus, MSBuild doesn't handle dependency management, which is completely retarded. You've got NuGet now, but again, Microsoft had to over-engineer it, to make it IDE friendly and thus the ease of setting up your own Maven repository is gone.
Yes it does via NuGet, and again NuGet has no dependency on the IDE
> And have you tried building MSBuild projects on top of Mono? Try it. It's fun ;-)
Yes I have, what's your point?
> Basically only a .NET developer that never experienced other environments could claim that MSBuild/VS.NET is satisfactory, but for the rest of us, it's like trying to do software development with early-2000 tools and IMHO, that's where the entire .NET ecosystem is.
Thanks for the personal and professional attack at the end there, nice touch
That is certainly the case. But I guess my point is both ecosystems are so completely divergent that it makes sense that .NET would be an uphill battle for shops not running it elsewhere.
I remember looking into MSBuild, but I couldn't get it to work. I must have had some path set wrong or something.
Most every command that can be done with a gui can be done via command line, mostly powershell; which you can use remotely. In fact I would be hard pressed to find any administration routine that cannot be done through command line and is not documented.
The thing that I could use most is a way to automate setting up a reverse-proxy on a given path. I've figured out the steps to make it happen in the GUI. But that is tedious and error prone.
Where would you suggest I go to find the best way to handle this?
Not true. I want still want the IDE compile, type check, and add type-safe completions (When using statically typed languages). I want the IDE to assist me in writing the code. I want my IDE to launch/attach to processes for debugging. Generally, I want the IDE to produce binaries yes, but mostly for my own consumption.
I want to be able to access the compiler external from the IDE so I can automate builds/deployments easily.
Now I want both types of builds to happen in as close to the same manner as possible so they're consistent, but both are important.
I always have the same problems when moving from linux over to a Microsoft shop. You really do have to approach VS differently than you would any other dev environment.
> fortunately those days are over and they've become mostly irrelevant, but everyone knows that given half a chance they'd do it again...
Everyone I know for the most part types their documents in Microsoft Word on Windows computers. Sure, they got smartphones and tablets for the media consumption and facebook, but they don't even know an alternative "big boy" OS exists. They think Windows == computers. Which I think means MS is anything but irrelevant (no matter how hard I try to stuff opensuse down everyones throat).
Maybe ten years ago I would have said that, but these days it seems they are typing their "documents" into an email composer or a website form (be it a frontend for blogger, wiki, wordpress, etc).
You mustn't work in an office environment then. The only significant break from MS products I've seen has been Lotus Notes... which was significantly worse than Exchange.
MS Office is the defacto file format for office work, and MS Office on non-Windows platforms (ie. Mac) is so bad as to appear intentionally crippled.
I work for an decent sized international company that not only has a presence on the web it also has factories and all of the complexities that go with that. I would indeed count where I work as an "office environment", I even have the cube, office badge and mailbox to prove it :)
It's not .NET, .NET is a fantastic framework. The problem here is you're not just selling IIS and .NET, you're trying to sell the entire Microsoft ecosystem. There are so many MS components that just don't work on the Open Source world.
Microsoft makes most of its money with its business products, so it's not cheap. Some companies just simply don't want to pay the Microsoft premium.
I don't think it's worth mentioning Mono. It's impressive what they've managed to accomplish, but it's nowhere near being a true replacement for .NET, especially for any serious system.
Not so much hate for me, but apathy. For your one CMS, there are dozens based in Rails, Django, Node based ones I've not even heard of, and same for Go. For any of those, I just need Sublime and a server of my choosing. Furthermore, I can do dev on my box (a Mac) with very little spin up time.
Contrast that to your scenario. First, I need Windows, which is fine for most, but not me. Then, my prod setup has to be Microsoft based. I've yet to find a $5/month IIS-based host with SQL Server (apathetically, I haven't looked much). Oh, and Visual Studio. I can probably get by with Express, but at some point I expect I'll find a wall that forces an upgrade.
Microsoft has come a long way, but when I started years ago, I couldn't swing a Microsoft-based environment. VS was prohibitively expensive, and my parents' crappy computer couldn't run it. But I could learn PHP for free, run it locally through XAMPP, and be off to the races. Microsoft's never won me back, and your CMS is paying that price.
The problem does ultimately lie with the tie in, I can appreciate that. I suppose my question was almost rhetorical as I know where the problems lie.
I wanted to redevelop our CMS in MVC (we missed the MVC train by about 2 months so it's Web Forms) as I like how much more lightweight it is but to be honest, I would rather completely redevelop in another language as it would help our adoption rate with our clients.
The painful thing is, I know how powerful our CMS is (to our clients at least) but it's such a hard sell.
We normally deploy onto our own cluster BTW as we roll out core updates through our own servers so everyone feels the benefits of new modules and admin updates etc so the hosting is generally taken care of.
I think people rarely take into consideration the cost of a project beyond the actual software. VS can save a lot of time – this extension is a good example.
Visual Studio's Python and Ruby plugins seem quite decent and free if you're on VS Pro and up. You don't necessarily need to let VS go if you're to migrate to a language supported on more than one platform.
I've been using it regularly for a few weeks now. Granted I'm a novice a Python, but so far I've found it to be outstanding. It offers almost all of the VS functionality that you would expect if you were developing in .NET, and it's quite stable.
.Net is the most popular platform for commercial content management systems($2k->$100k license), with SiteCore, EpiServer, Kentico, Sitefinity and Ektron leading the pack.
If you have problems selling due to the platform, I think the main issue is your target market, and not .Net in itself.
I don't get all the hate?