Everything's been downhill since VS6. I'm only joking, but seriously, does anyone remember how lightning fast VS6 was? That was over 15 years ago with much slower computers. I guess application 'snappiness' has not been a priority for the Visual Studio decision makers.
I've used VS since the late 90s (writing node.js in ST2 now) and honestly appreciate the hard work and cool features that goes into it. The new VS2013 feature that shows how often a function is referenced is useful. I don't get that in ST2 and probably never will. But I've used VS enough that I've become philosophically opposed to it and other similar IDEs. The core of the problem for me was that all the fancy wizards and project templates are not maintainable for MS. There were a number of times I was using some new project type introduced in a version of VS only to find the template was incompatible in the next version (e.g. reporting in 2005). This inevitably lead to a lot of unexpected work when my team would upgrade. Many of the productivity wizards impose hidden debt on their users.
Another major gripe was that VS would get really sludgy for solutions with a great number of projects/files. Take note that whenever you see MS demo a hot new feature, it's always with a very simple solution. Also, VS would block for me a lot, but that was probably due using too many plugins. I'd find that an application freeze of even 2 seconds would distract me. Not an issue I face now with a text editor + repl.
I think you may have selective memory with regards to VS6 (understandable over 15 years). Having recently worked at a company that for silly reasons did not upgrade beyond VS6, it was not lightning fast, took several minutes to open, and crashed frequently even with smaller projects.
Modern VS really needs to work on managing large projects- but this isn't something it ever had to begin with, and has certainly improved since VS6 despite added functionality. The responsiveness issues you list seem a little more problematic than normal from my experiences- I would definitely try uninstalling a few plugins and seeing if that helps.
Bingo. I've regularly worked with 15+ project solutions, and never noticed much hanging. Read through this guy's entire comment wondering what he was talking about until I got to that part:
> Also, VS would block for me a lot, but that was probably due using too many plugins.
Yeah, that's where your problem is. I'd put good money on ReSharper being the problem, as it's slowed me down in the past. Uninstalled it and never had another problem. The only plugin I have now is VsVim (which I highly recommend for those who'd like vim bindings.)
Chromium is an extreme case of this. When we started we wanted to live the VS way of life (IDE tools and the like), so we had a Chrome.sln and various projects. Eventually it became too much. It would take minutes to load the sln, and woe to you if you synced your source tree while msvs was open, as you'd receive a neverending slew of modal prompts asking you to reload each of hundreds of projects. I think we still have a msvs build, but most developers use ninja on Windows, and just use msvs for debugging. The sad fact is that addons like Visual Assist X provide many of the benefits of the IDE without requiring projects to be loaded.
How many projects does chromium have? I typically work in a solution w/ about 175 projects and it only takes about 10 seconds to load up for me on 2012.
It's a single product, composed of multiple projects/targets building different dlls/executables. That was my understanding of the point of a "solution" (vs the old days of VC6 when there were only projects and workspaces). Anyway, it used to work back in the days when most of Chrome's code came from WebKit. Now we're many times bigger. It's clear MSVS' project UI is not intended for building projects of this scale. I'm assuming Microsoft doesn't use this UI to develop windows, or office, so it's not surprising this case isn't supported.
I have no idea what the Windows or Office people do, but the Visual Studio group certainly does build their own software in VS. (Or did as of mid 2009 when I quit, anyway.) It was not a particularly pleasant experience!
I disagree heavily. Stock VS is very fast. However it does slow down significantly when using a plugin like ReSharper.
But for me in the end it is worth it. Show me any text editor or IDE that provides the same number and quality of productivity enhancing features as ReSharper that isn't as slow or slower.
R# 8.0.0 had a bug where it would crash VS from time-to-time. I ran `devenv /safemode` to load VS without any third party stuff in an attempt to identify the problem and my god, it was fast.
I have a 28 project solution, and with R# the IDE is still plenty fast but every so often I think about just how fast VS was without plugins.
Not worth it for me. I have a very fast system (i7, 32GB, RAID 0 SSD), and ReSharper slows everything down too much to be usable. I'm not sure if it's the projects I work on -- I've used it usually on pretty large ones like Orchard CMS so that might be part of it.
VS6 was very fast, but its compiler was bad at standard compliance. GCC was much better. The newer MS compilers are way better at supportiung the standard and they also did a great job integrating the new language features. So I would say there is significant progress since the days of VS6 :)
That being said, VS 2012 works pretty fast for me (I'm on a fairly beefy machine though).
How many projects do you consider to be a 'great number'? I ask because I do development in VS with solutions that contain around 300 projects and don't experience anything close to what I would consider 'really sludgy'.
Cool. I see in another response to your post that someone mentions minute load times just to load up the solution file, something which I thankfully have not experienced just yet.
Makes me wonder what's accounting for the varied performance? Probably some combination of project size, plugins, and machine specs, I reckon. If one mans (persons) 10 projects contain 100x the code that my 50 projects contain it would certainly make sense to have longer load times.
I got bit by being really productive in VC6 like 10 years ago. Had a script to clone a template dsw/dsp file, which make a new one, so I have about 400 projects like that, for little experiments, little projects.
Upgrading each of these projects to the 2010/2012/2013 IDE requires about 5 minutes of manual steps - per project!
I still keep a VC6 on my machine (even though it barely works on Win7) because of all that.
What got me stuck on VC6: I benchmarked OutputDebugString in the 2002/2003 versions, and noticed that they were ~10x slower.
VC6 was notable for simply discarding OutputDebugString output when things got busy. This was a problem I used to suffer from quite regularly, and it caused me a lot of bother.
I have no idea just how they managed to utterly fuck up the performance in VS2002 and later, but it does at least capture every last char of output, if you have the patience to wait for it.
(Perhaps on modern multi-core multi-GHz CPUs the VC6 approach is reliable enough, assuming it's some timing issue. But I have to say that I do prefer the VS2002+ tradeoff. Wish somebody would just fix the whole sorry mess though.)
VS6 was a massive downgrade on VS5, in that the help system was no longer treated as a dockable window within VS. I relied on the documentation at that point, but when VS6 came along it was no longer something I could easily have in front of me, with my code, with the VS window full screen. </nostalgic rant>
The initial load is slow. VS is a huge system with a lot of plugins. But I think it's still quite fast. I generally do VS on the fastest computer I own, which sucks, but oh well... it's still more usable and faster compare to Eclipse.
You could see this in the Autos window in earlier versions, too. Although maybe only immediately after shift-F11'ing out of a function, and not of multiple levels of function calls like the linked article shows.
VS2012 took out installer projects (instead telling you to just use InstallShield), SQLCLR projects, was incompatible with Oleg Sych's T4 Toolbox plug-in, and had a colour-scheme in the TFS source browser that made my eyes want to bleed.
Every other VS upgrade has been comparatively painless. I can't say I'm excited to try VS2013.
I think the problem here is that VS needs to satisfy the needs of many different types of developers and also try to appeal each ones personal preferences.
Personally I am enjoying VS2012 a lot and it is really sad that there are hardly other IDEs this good.
I completely agree. I've gone through plenty of good IDE's in the last year. From Dreamweaver, to Text Mate, to Komodo, to Aptana.
I started using VS when I landed in a .Net shop and it made sense to use it. Totally blown away by some of the cooler features you can't find on any other IDE. Even the free VS Express (which I now use at home) is so much better than other IDE's out there.
Someone decided that it needs to pander to web monkeys instead of empowering users that have used VS for 10+ years.
Which it probably does, given the huge amount of development that is web-based these days. The market for Windows-based C# applications is shrinking by the day.
It's not necessarily "monkeys", but, disturbingly, Microsoft developer tools are becoming more and more oriented towards "wizard-and-designer-clickety-clickery" type development.
There are a few exceptions to this rule (think EF Code-First), but that's a drop in the ocean.
If anything MS tools have moved away from clickety-clickery. That was something they were pretty much famous for back in 2008. MVC and EF are just a couple examples of moving away from this patter. This is nothing but imaginative revisionism.
Don't get me wrong, this type of thing drove me from the MS ecosystem a while ago now but they do move largely in the right direction, just too slowly for my tastes.
Agreed - EF code-first, Nuget, and ASP.NET MVC in general are excellent steps in the right direction away from excessively tool-oriented / ultra-bundled / abstracty type things. The very dark days were pure ASP.NET web forms with controls, DataSets, DataTables, ClientScriptBlocks, and the like.
A lot of things in VS are wrappers around very well-documented CLI tools, e.g., svcutil, and I don't begrudge these tools for doing a lot of heavy lifting.
I kind of disagree with this sentiment. From my experience the tooling around editing source files (csharp, razor, javascript, css) has gotten a LOT of love in the past 2 years. You're probably correct in that more work has gone into web development use cases over traditional desktop software, but not much seems to have been added in terms of "visual" programming.
On the designer front I can think of Entity Framework designer and WWF designer, Build Template designer (or however this thing from TFS is called?) and possibly a couple more.
My biggest gripe are all kinds of wizards, most notably "New Project" ones. They do generate a lot of cruft I have to clean up later and pull way too many dependencies.
AFAIK, Visual Basic was targeted at non-professional/beginner programmers, so having wizards and designers is fine there.
My main gripe with abundance of today's "visual programming" is that we have memory-managed languages with immense expressive power and ability to write all kinds of DSLs, yet what Microsoft does is it provides crippled XML-backed designers along with half-baked frameworks and class libraries.
Microsoft has always had "half-baked frameworks and class libraries".
I actually like MFC, but it never really got past the "good for a first cut" phase, IMO. Fortunately, I've never had to deal with .NET, and besides a little MFC, most of my work is on Linux these days.
Ya, I can't begin to tell you the number of times I have been made fun of by ___ text editor fanatics for using an IDE that has wizard clicky things/drag drop components etc
The powershell prompt to manage your nuget package dependencies on a project is pretty much the opposite of 'clickety' development. The F# interactive prompt, likewise.
MS have always done a good job of catering to a wide range of developer personas.
Enterprise developer here. That wizard bullshit is 100% enterprise. It's horrible to use and only exists because most enterprisey programmers are too terrible to grasp more productive coding methods.
Still 100x better than digging through 100 pages of abstruse Java docs about AbstractProxyBeanDAOFactoryProxy.GenerateAbstractProxyBeanDAOFactoryAccessor though.
It's weird, because my experience of .NET enterprise development recently has been of people with Java-envy needlessly using Unity, and every other enterprisey framework they can get their hands on, for even small projects.
I felt that way when I switched from m.exe + cl.exe to Visual C++ but I eventually got over it. There's actually some pretty cool stuff happening at the lower levels, check out the "Going Native" stuff on Channel 9.
It's not necessarily "monkeys", but, disturbingly, Microsoft developer tools are becoming more and more oriented towards "wizard-and-designer-clickety-clickery" type development.
The term "wizard" came about because of the AppWizard and ClassWizard features in Visual C++.
Clickety-clickety has been a goal of Visual Studio since before it was Visual Studio.
I don't think the comment was intended to be derogatory towards web programmers, so much as annoyed at the "you can create a website in an hour without writing a line of code" oriented features. Some of the web-oriented stuff in VS over the last several years seemed to be targeted towards mouse-oriented design of small web apps rather than more serious web programming. I do not think that is still the case, though I haven't really been paying attention.
It’s really not that bad. WiX is actually pretty decent, definitely not a “disaster”. It might look more frightening than InstallShield because you don’t get a nice UI that allows you to set up an installer with a few clicks, but I mean, we’re programmers here, surely editing textual configuration files is not an issue? It took me somethong like 30 minutes to replace our old InstallShield installer with WiX.
I gave it a shot for a day recently but found it way harder to use than InstallShield or NSIS. Part of it was probably the broken documentation where half the links just ended in nirvana. But I gave up when I learned you really have to add each single file one-by-one and the documentation even defended this as a feature.
You can use this Wix tool or command called Heat, which will automate the adding (and creating GUIDs) for a bunch of files. Really it's the underlying MSI target that's so painful, especially when you get into versioning. The OS wants to have detailed information on every file that is part of your installation. I think this is primarily for uninstallation purposes, but also for upgrades and who know what else. If I could get away with it, I'd just use NullSoft. It's like writing assembly, but it's so much simpler.
With Wix/MSI, there were certain executables that I could never get it to run as part of the install process. The XML would look the same as other execute commands that worked, but I could never figure out why they didn't run.
This can "kinda" be worked around with "heat.exe" (don't get me started on naming of tools in the toolchain), but even then you'll need to explicitly specify half a dozen command-line arguments (-ag -dr -cg -srd -scom -sreg -svb6 -sfrag) to make the thing work.
WiX is a thin wrapper around MSI (which sucks beyond belief) and as such it suffers full blast from all the "design" decisions of the latter, not even trying to remedy the situation.
I really could pour out a full-blown rant on MSI in general and WiX in particular, but that would be wildly offtopic and of no interest to fellow HNers.
If you think MSI is bad, and I'll have to take your word for it, what MS had prior to it was probably worse. Writing installers for Windows using MS tools has always been a nightmare.
He's not wrong: WiX is a horrorshow. It's unintuitive, difficult to read and parse, and is saddled with much of the cruft of years of Windows; when you compare it (or NSIS, or InstallShield) to building an .app (or even a .pkg) under OS X, it fares very poorly.
Wait, weren't you complaining about all the "wizard clickety clicky" things in another thread?
If you hate wizards, and you hate "obscure incantations", which I'm assuming means code, then what do you like? Do you program in natural language with voice recognition?
By "obscure incantations" I mean having _three_ different syntaxes for string interpolation/variable substitution, providing _six_ command line arguments for the tool so that it does the one reasonable thing, having illogical rules in comparison operators, having to use a frickin' _bootstrapper_ to install prerequisites and not being able to chain MSIs, not being able to have a single installer for x86 and x64, not having a _simple_ way to define logic for "Back" button, yet having to write heavily nested XML to do simplest thing.
It's true that msi is different from other installer builders, but it's for a reason. And if you have a concrete project you can build while following along with the wix tutorials and book, it's not difficult, it just takes some time.
Yeah, the "reason" being that Windows Installer was designed to support corporate deployment of applications to shared machines with install-on-demand and roaming profiles, and to support Windows 95 and up. This, and Microsoft's manic affection to backwards compatibility plus "architecture astronautery" (on-demand installs of COM objects, anyone) makes MSI a disaster.
The fault of WiX is that it's too thin of a wrapper.
I've always liked InnoSetup (http://www.jrsoftware.org/isinfo.php). You describe your installation in a short file created via its syntax-highlighting IDE. A big con is that its scripting is done in Pascal, but you can likely find existing scripts to do many common operations.
While that's obviously a solution, it's not quite the same y'know? There's a lot more skill overhead in learning that tool vs the comparative ease of the installer project.
Considering how thoroughly MS screwed the pooch on ClickOnce, I was genuinely surprised when they completely abandoned their working installer system.
For small things ClickOnce is fine, but it's a pain in the ass to automate. For example, there's no way to synchronize the 'version' of the installer with the version of the EXE it's installing. I had to hack[1] it so I could pull the version metadata off the EXE assembly and then force it into the XML of the project file where the ClickOnce settings are stored.
There's also no ability to publish the built installer outside of the UI- my build scripts had to build the /app.publish directory and then just copy the whole shebang to a network location for deployment. I'm not as upset about this being a separate step, but if they indeed allow you to configure and deploy the installer from within the UI why not expose an API to do it as well?
Overall I think ClickOnce is fine for internal, self-updating tools. It's worth noting, however, that I was inspired to create my workflow based on looking at what Github was doing with their windows client.
My powershell isn't _great_, so forgive any powershell oddities, but notice how much you have to massage the output of the mage tools to actually get it to do what you want.
Very nice. I really love 2012 and the 2013 RC was pretty solid as well. The step up from 2010 was the most pronounced, as 2012 just runs circles around 2010 in (albeit, my own anecdotal) performance.
Just gotta wait for an upgrade license of R# to go on sale, as R#7 isn't compatible with 2013 ;(
For what it's worth, I got a 50% discount from them from buying R#7 so close to the R#8 release date (uninstalled 7, and mentioned in the "please tell us why" comments that it was just too expensive). May be worth a shot.
"There are now dozens of large applications written by teams in Microsoft, including Bing, Xbox, TFS, So.cl, as well as in projects such as Adobe Digital Publishing Suite for Windows 8.1, Zud.io, Away3D, and Turbulenz."
I think they've been pretty serious about it from the start due to the design decisions in Metro.
Support for large projects/solutions was greatly improved. VS2012 added deferred loading for some items so you can open and get into code faster.
Of course, this is purely an artifact of overly large solutions. If you've inherited any of those, as I have, it's worth the upgrade for the improved performance, IMO.
While VS 2013 has much better C++11 support it's not close to full compliance. The Visual C++ team have decided to work on C++11/C++14 together which is slowing C++11 a bit.
Here's a blog post laying out their plans.
http://blogs.msdn.com/b/somasegar/archive/2013/06/28/cpp-con...
Man! If you're doing C++ then you definitely want to get onto 2012/2013 ASAP, the improvements in tooling are amazing. "Navigate to.." alone is worth it.
VS 2008 is the last one capable to compile the C++ to produce the binaries that can run on Windows 2000. Believe or not, I actually need that. That prevents me to use any C++ language changes introduced after VS 2008.
The frustrating part is that MS actually removed the existing code from the already existing libraries (but which are not binary interchangeable between the compiler versions) in order to disable the support for Windows 2000. Otherwise I'd be able to use even VS 2013. They did the same for XP with VS 2012, but more people made the fuss so now even VS 2013 should support XP, AFAIK.
That's "MSDN Magazine Camp". MSDN Magazine was a rag of a publication that was mostly just advertisements for 3rd party tools than it was anything interesting about programming. MSDN is the Microsoft Developer's Network, which houses basically all of their documentation, tutorials, articles, and support for developers.
Wow, a long article but still relevant. As I was reading this I realised how closely it matches even the latest metro ui fiasco (for developers). Indeed "MSDN Camp" has won. Thanks for the link!
I use VS2008 for C++ and VS2012 for .NET. I upgraded our C++ projects to VS2012 as a proof-of-concept and build times went from 5 minutes to 15.
Our projects aren't particularly great, virtually everything is in stdafx.h directly or indirectly and small changes results in rebuilding. The increase in build time would have hurt us.
VS2013 is a bit faster (~10 minutes, last time I checked) but still a bit of a hit. Allegedly this is due to the extra time parsing the C++11 language bits.
I don't think this is a huge deal (our code should be better), rather something to bear in mind.
Also, if you recreate your project instead of upgrading it you'll end up with a default instruction set of SSE2 (instead of SSE) and your exe will suddenly not run on Athlon XP-era chips.
> I think the improvements we'd get in Entity Framework performance
Technically, that's not a VS2012 or 2013 feature, that comes from .NET 4.5, which you can use with VS 2010.
However, the testing and analysis is well worth it. I don't know what your source control is, but paired with TFS 2012, it's a pretty large productivity improvement for my team over VS 2010 (as large as you can get from an IDE upgrade).
IMHO the killer feature with VS 2012 is C# 5 and await/async. It takes a good afternoon to get your head around it but is totally worth it (unless you develop CPU-bound web applications exclusively, I suppose).
I'm still on VS 2008 as well. Is there anyone who has upgraded a substantially sized C++ project from VS 2008 to one of the newer versions that would be willing to share their experiences?
Yes. 700 of them in fact, from VS2008 to VS2010, a couple of years ago. Here's what I found...
- VS2010's macro system is just broken, and fails to coexist with VS2008. Basic macros using the DTE object work; more sophisticated ones (I have a few that used DTE90 - or was it DTE80? - anyway, whatever, they manipulated project properties) seemed to be literally impossible to make work, due to some kind of conflict between system-global components that both try to install. Pretty shameful.
- VS2010+ craps massive files into your solution folder, worse even than the NCB palaver, and so your more junior and/or inept programmers will keep checking that junk into source control.
- It's common in VS2008 to change the build product name by going to the Linker or Librarian property page and just changing that Output File property. VS2010 doesn't like this, though, due to some MSBuild limitation, and would much prefer you to modify the settings in the General page, leaving the output file name as its default of something like "$(OutputFolder)$(OutputName)$(OutputExt)". Of course, the project upgrade doesn't actually do anything about this for you, so after importing all your projects that work the old way way, they won't work properly, and you have to fix each one up yourself.
- VS2010 dependencies aren't like VS2008 dependencies. There's a new C#-style References section that manages the linking. Dependencies can still be set, but they only affect build order. (Also - when you change dependencies, you need to close and restart Visual Studio, because sometimes they don't take effect properly.)
- The new C#-style references are part of the project, not part of the solution, so they come with the project when you add it into a solution. Add a project but forget its references and you just get a cryptic error (along the lines of "Project has no Debug|Win32 configuration") when you try to build; to add insult to injury, when you go to the References page, the missing reference is not actually shown, because (of course...) it's not in the solution. You need to open the vcxproj in a text editor and look at its contents and compare it to the references VS2010 shows you to work out which is missing.
- When a project refers to a non-existent file, the project will be considered permanently out of date. VS2010 won't give you any clue about what's wrong, and to track the problem down you (as I recall...) have to change some random setting in a file you've never heard about, which gets MSBuild printing stuff out via fucking OutputDebugString, leaving you to scrape through its (unreadable) output with DbgView until you find the magic message that hints at the file in question. (The link I have in my notes is http://blogs.msdn.com/b/vsproject/archive/2009/07/21/enable-...)
- If a solution refers to a non-existent project configuration, you get a cryptic "The parameter is incorrect" error when trying to build, with no clue as to what's wrong.
- If you happen to open one of the built-in MSBuild files in the text editor, which can easily happen if you click on the wrong warning, all hell breaks loose and MSBuild starts to spew warnings everywhere each time you build.
This excludes a few vendor-specific issues I had, with my favourite (I think...) being the plugin that would instantly terminate Visual Studio if you used the phrase "%(ProjectFilename)" (instead of "%(ProjectFileName)") in your build output paths.
Needless to say, after this dreadful experience - and I have to say that if you have never embarked on an endeavour such as this, you probably won't (as I didn't) appreciate just how long it can take, and how time-consuming it can be to track down and fix all these issues ocurring in all these opaque black boxes - I swore off VS2010 completely. And to this day, I have yet to use it in anger.
Since moving to OS X, I've left Visual Studio behind. At first, I had a boot camp partition running windows so I could still develop our C#-based web product. Then eventually we changed the product significantly enough that moving to an OSS tech stack made sense.
I'd probably still be using some MSFT technologies if I could use a VSS-style IDE on OS X without virtualization (I tired MonoDevelop, but it just wan't the same). I didn't have issues with the speed of Visual Studio running on my beefed up MBPro, but the keybinding stuff was just too much to deal with.
Not to mention, having a ton of different runtime/hosting options is a pretty nice bonus for the OSS stack.
Also, for mostly web apps, I think Visual Studio is massive overkill (but I'll still watch their videos on features).
For now, I've settled happily using on cross-platform tools (PyCharm/WebStorm for a feature rich IDE and Sublime Text 2 for code editing, and VIm when tweaking stuff on the server). Should I ever go back to Windows (likely, because I want a Surface Pro 2), my tooling should carry over (though I'll have to go through some keybinding issues again).
Never again will I use products that are locked down to a single OS. Even the tools on my Mac (with the exception of Keynote) run on Windows and vice-versa.
VS 2010 is the last one I got for personal use. Not enamored with the changes in VS 2012, Windows 8.* nor the cyclical abandonment of APIs. Add in the increased license cost we face on all Microsoft products at work and any announcement from Redmond gets a "meh" from me.
VS 2013 adds fix-and-continue to x64 builds. That right there is enough for me.
Beyond that, though, I'd encourage you to at least look at VS 2012, get past the superficial changes, and look underneath. There were a lot of performance improvements in the GUI rendering that added up, and there were a lot of tweaks to project search and management that became indispensable to me shortly after launch.
In VS 2012 MSFT removed the color for the icons in the UI. Everybody complained on the web. Now the color icons are back. MSFT's spin:
"Visual Studio 2013 includes many user interface improvements based on customer feedback and Microsoft’s core design principle of keeping the focus on the content to deliver an improved user experience. You may notice the more than 400 modified icons with greater differentiation and increased use of color,"
So they put it back and now people are unhappy a company didn't flat out say they made a bad decision? Spin is everywhere, startups seem worse than others. Every day there's something on the HN front page that's going to revolutionize and disrupt the internet...
No, I'm unhappy that they kept the capitals in menus(!) like "FILE" "EDIT" "VIEW" "PROJECT" "BUILD" even though there were enough complaints about these too. I'm also unhappy there's no real Start menu back in W8.1.
Because from the very beginning, way before 2012 was released, customers hated the move and criticized it. Microsoft insisted "Metro" was cool and we had to like it, that they weren't icons, but glyphs, and glyphs don't use color.
Instead of just admitting up-front their redesign was pretty hated and promising to fix it, they insist it's great until they've changed it.
Imagine one day you can just loan Windows Azure server and launches a build when you click a button on VS web edition. I think that's an attractive feature. Or pair programming on web over VS with co-workers.
There are few new features I actually need. I want speed. Speed when compiling(currently it's file-copy mania), speed when starting my project(minutes of loading debug symbol, really?)
I can see a banner about halfway down linking to DreamSpark. They still only have the RC, but apparently the final version will be available on the 31st.
The VS.NET installer has gotten a lot less terrible since the 2005/2008 days, although it used to be pretty dicey. One may now upgrade with little to no fear of a nightmarishly borked install state... that said, it's wise to use VMs exclusively for development, so rolling back to a pre-update snapshot is an option.
I heard many complaints about SP1 slow starting and getting stuck in 'Shutting Down'. On top of that SP1 has zero new features. Bunch of so called security updates. From my perpective i'm using the stable version.
If thing go awry i would need to waste a day or two reinstalling the OS again. It's very easy to resist installing this update.
Microbenchmarks like these don't usually teach you a whole lot, other than how far someone went to implement the benchmark, and how close the benchmark is to the designed application of the libraries used in the implementation.
To be fair, They're using Entity Framework in there. That adds a lot of overhead for something as simple as running a single query, and spoils the results.
Everything's been downhill since VS6. I'm only joking, but seriously, does anyone remember how lightning fast VS6 was? That was over 15 years ago with much slower computers. I guess application 'snappiness' has not been a priority for the Visual Studio decision makers.
I've used VS since the late 90s (writing node.js in ST2 now) and honestly appreciate the hard work and cool features that goes into it. The new VS2013 feature that shows how often a function is referenced is useful. I don't get that in ST2 and probably never will. But I've used VS enough that I've become philosophically opposed to it and other similar IDEs. The core of the problem for me was that all the fancy wizards and project templates are not maintainable for MS. There were a number of times I was using some new project type introduced in a version of VS only to find the template was incompatible in the next version (e.g. reporting in 2005). This inevitably lead to a lot of unexpected work when my team would upgrade. Many of the productivity wizards impose hidden debt on their users.
Another major gripe was that VS would get really sludgy for solutions with a great number of projects/files. Take note that whenever you see MS demo a hot new feature, it's always with a very simple solution. Also, VS would block for me a lot, but that was probably due using too many plugins. I'd find that an application freeze of even 2 seconds would distract me. Not an issue I face now with a text editor + repl.
</rant>