Sadly VS 2013 has a huge regression which makes it a no-go for my team over at Stack Exchange, any changes made to the server settings are saved to the project file rather than the per-user settings file, it's been reported but doesn't look like it's going to get fixed soon: http://connect.microsoft.com/VisualStudio/feedback/details/8...
I definitely second this. To me, to a large extent Scott is the voice of Microsoft. I still look back at his answer on Quora regarding why Microsoft as a stack and am amazed at his ability to largely remain objective.
It seems to this curmudgeon is that the bug is in the whole metaphor of a "project file" being storage for a bunch of UI state set in a bunch of configuration tools and not, y'know, part of the source code of the project and subject to the same kind of engineering process.
You play this kind of game with "automation" and you get burned. Build, configuration and deployment management are hard software problems and they need to be solved by smart people and real tools, not checkboxes and file selectors.
That gets to a semantic argument. Yes, the project file is a text file that can be editted. But editting it is not the natural form for making changes, which is an important part of the definition of "source code". The natural way you make changes to it is to click on junk in a GUI, and that means your changes are going to be inherently filtered through whatever policy decisions the GUI tool made. And that's a huge flaw from the perspective of engineering process.
You can't hack what you can't see, basically. And changes to the project file (or whatever other "wizard guided" IDE output you're using) are opaque by definition.
This is uninformed FUD. You can "see" what's in VS's project files just fine. The file format is straightforward XML with fairly obvious semantics. Having worked with both VS's .csproj files and UNIX makefiles, .csproj is far far easier to understand and make changes to. I dive into it all the time. The most common case is when I've got WIP changes that conflict with another dev's checkin and I have to resolve them by hand.
Just because they supply a GUI doesn't mean it's the only way to change project settings. I'm not sure what led you to believe that.
If it is a text file you manually edit, then those changes are going to be inherently filtered through whatever policy decisions the tool that reads that file makes.
I am having a hard time truly understanding the difference (not that we use VS stuff for deployment anyways, but that is for other reasons).
A developer could add custom deployment info to the manual file and accidentally commit it just as easily.
You just do not like GUIs (which is a perfectly acceptable stance) but it has nothing to do with some fundamental difference.
There's no 'natural' way of editing the project files: if you think that the 'natural' way of doing it is by clicking junk in a gui, then you are assuming too much.
While I'm probably in the minority, I edit my *.csproj files by hand and build from the command line for several of my projects. I do this for the exact reasons that you mention: I like control in the engineering process.
I'm unhappy that VS 2013 is putting user settings in the proj file willy nilly and I hope that it's fixed soon.
This. Visual Studio to be blunt is a fucking nightmare in this department. It's cost us hours fixing configuration problems. We have 50 developers though so are a large team.
I agree. I love Intellisense but I wish Visual Studio would stay the fuck out of the way everywhere else. It's particularly annoying how all the checkbox settings are only applied to the active configuration unless you change a dropdown menu... can't even count how many times I made a change to Debug/x64 only and then had to go back and fix it later.
Same here. I'm in the habit now of making sure that I've selected all target configurations, then all target architectures and then put the settings.
But even then, I need different settings for debug/release or x86/amd64 - and it's not really helping when there is incosistent naming across SDK's coming from Microsoft itself - where you can't match with one variable (say $(Target)) the given architecture, and it seems every group at Microsoft follows different conventions of how to name things.
Well they fully acknowledged it's not a desired behavior and apparently they plan to fix it:
"Posted by Microsoft on 9/23/2013 at 3:03 PM
Thank you for bringing up this issue. Unfortunately, this functionality was lost when the web project properties page was refactored. We are working to get this feature back into the product.
For now, if you have a project with this setting unchecked in VS 2012, and open it in VS 2013 it will respect your individual user settings until the first time that the servers section is modified on the web project properties page."
I had to re-do our TeamCity integration when they stripped out the IIS Path property out of the project file in favor of publishing profiles. For a shop like ours, where we have lots of small projects, automating the deployment is pretty critical. I don't want to have to add 120 publish profiles when previously I could rely on the project settings.
Ultimately, we hacked together a fix, but I'm still wary of their changes.
So basically you're saying is Stack Exchange development team does what ever the fuck they want to do? 10 developers can have the project setup 10 different ways? :S Nothing worse than going sitting with a developer to find out their setup is fucked.
This bug is more of an issue for OSS than a company. IMO.
There is a big difference between allowing devs to do "whatever the fuck they want" and the degree of standardization you are talking about. Every team I've worked on has adopted tools and coding standards that everyone has agreed to follow (and been held accountable for following), but coders were allowed to tweak their machines and editor settings to their liking.
Unless you don't trust the basic competence of your team (in which case, it is probably time to find a new team), I don't see the need for that degree of uniformity.
Did you read the examples in the link? The issue is with different server settings when running locally which is one of the configuration settings that I think anyone can edit to anything they want. Why is it outrageous if someone wants to run their local server at a different port than someone else?
At this point I'm fairly certain you're just trolling me... can you give me any example of why you frown upon running with different local configurations?
We have a dev environment where all our code builds upon checkout and then we have our own local environments to actually do development on. What's the problem with someone deciding that they want to run at hostname alias so-and-so on their local machine or port whatever instead of what's the default?
Sadly, I've all but stopped replying to anyone with less than 500 karma here. Karma is so easy to get on this site that anyone that's been here for any length of time that can't get over that threshold is probably either intentionally trolling or has difficulty with common courtesy. Case in point, where philliphaydon came out blasting with:
So basically you're saying is Stack Exchange development team does what ever the fuck they want to do?
You didn't give anywhere near enough information for someone to come to the conclusion he came to. And the anger with which he presents it is uncalled for.
I've been here for far longer than you and I'm still stuck in the 300 karma range. Why? Because of my timezone. Most people are asleep when I'm awake.
It is virtually impossible for me to submit an article and have it viewed by a large number of people before it is pushed off the front page. So all my submissions get low score, only for the same article to be submitted later in the day once NY and LA have woken up and get big karma scores for someone else. I've given up submitting, which is how you accumulate the big karma scores.
This is TFS and lots of project management tools in the cloud. TFS covers a lot of core stuff such as bug/work-item tracking, Scheduling/Planning, source control and automated builds. You get a reasonable baseline for free, and pay for usage after that.
It looks like it integrates with the Azure portal. Although a 'windows box' is required, this integrates with the free VS2013 Express editions as well. Props to Microsoft for bringing better developer tools to their environment.
I think you need a Windows Azure account, not a windows box -- I've seen someone using VS Online on Macbook Pro/Chrome, IIRC. (Can't remember where, though.)
Scott Hanselman used an Azure VM to run VS2013 and tools, and remoted into it from a coffee shop using a Surface 2 (the 'RT' flavor, not a full desktop). It's a nice way to work from lower power machines. To do this, of course, does require an Azure account, and after your 'intro' phase would be paid.
The support services provide things like source control, work item tracking, and similar 'in the cloud' but they work with your VS2013 install, wether on a desktop or on a VM on Azure.
i Actually love git integration with VS 2013. It seem to automatically detect that project is under git and enables whole bunch of features such as right-click diff, undo checkout and so on.
TFS has a lot of features and a lot of configuration options. What is nice is that all of the parts can be put together to work across the entire development team's workflow and life-cycle. So developers, QA, project managers, Ops, etc all have a part with-in how TFS is intended to function. As a solution, this integration allows for a single solution for various aspects of team reporting, projecting, etc. So rather than having to put together all sorts of different tools for the various parts of development, TFS is a unified package. Like all software development panaceas, there are issues and problems with TFS because it can be a big and bulky thing to administer, train people to work with, get team buy-in, etc. So in some ways, it is better for an organization to grow itself with various tools that have little to no integration with each other for their specific development needs.
Anyhow, I say all of this because I was, not too long ago, brought into a medium sized organization that was using TFS and was asked to evaluate it against other options. What I found for this organization was that TFS was probably a best solution for their particular development process (very much a MS shop) but that they had both a poorly administered system (with most all of the reporting and project management features broken and with almost no direct QA feedback) and developers that were untrained on how to utilized all but the most basic features of the system. What made this audit particularly interesting to me was how the most productive people in the organization disliked TFS while most others were either indifferent or liked TFS because they had figured out how to game the few features that worked. So, yeah, in that case, TFS was "beyond terrible."
TFS is not a solution I would run in a recommend wholesale but it has a lot of nifty if you look under to hood.
Or maybe you think that TFS is visual source safe and well, that wasn't too great.
Even prior to TFS2013 there was a git-TFS bridge to let you check in code outside supported platforms. I'd looked into it for an xcode project but thought it looked really awkward for something I really needed to trust.
I disagree with a lot of VS UI ideas (all caps menus?) but VS still remains the gold standard for IDEs. C++ IntelliSense makes me immensely more productive in a very tough language to parse. And UI designers like WinForms are 100% more pleasant than laying things out in code.
OK, I'm a long time emacs guy and not the target market, but I'm genuinely curious about the IntelliSense claim. Really? Are there any screencasts or whatnot I can look at to see an expert developer demonstrating that they're "immensely more productive" than just typing the symbol names?
Honestly my experience is exactly the opposite: I watch windows people try to edit code and wince. Their hands are bouncing to the mouse and arrow keys constantly. They mash keys and wait for key repeat instead of deleting marked regions. They pop dialog boxes up to search for things and have to move them around the screen to see.
And yeah: sometimes they press some kind of button and get a big list of symbol names that they end up staring at for a while before picking one.
It all just seems like a mess to me, but I'm willing to be educated.
I find it to be useful as a discovery tool. I can type
String.
and then it'll present me with a list of methods and properties on String. And then, when I've typed String.Substring it'll tell me what the arguments are.
For stuff I use all the time it isn't so useful, but when I'm unsure it's a lot quicker than running off to read an extensive reference guide. (and type completion is a time-saver too - no need to type out full variable names)
This sums it well. Intellisense is a discovery tool, not a productivity tool once you have discovered. Intellisense helps you write code without having to StackOverflow all the time.
Your criticisms are correct, but when people say "Intellisense" they refer to more than just command completion. When you hit that "." or "->" or "<ctrl>+<space>" or whatever, you can see (and navigate with the keyboard):
- The full type signature of the function and its arguments (including generic/template parameters and constraints)
- Whether any of the arguments have default values and, if so, what they are
- Whether the last argument is a "params" or "..."
- The XMLDoc describing the function and every argument
- A scrollable list of every overload for that function name
Invoking Intellisense when not completing a function tells you:
- What code objects are available in your current scope
- What type of things those objects are (property, field, method, overloadable method in a subclass, ...)
- A list of snippets you could invoke from that point
All of this can be configured to show up automatically or only when invoked with specific key combinations. Also, the Visual Studio team has somehow made it so that all this stuff stays out of your way even when it comes up automagically. I've never seen any other IDE come close to being "always there yet unobtrusive". This includes Eclipse and they do it pretty well.
The biggest issue I have with your argument is that, while it's true that watching someone fumble around with their mouse while coding IS pretty painful, Intellisense is NOT the cause.
You didn't make this argument but I want to address it: I watch people who use vanilla Vim when they code (I can knock them because I tend to be one of them). What do they have on their other screen? A browser with some combination of google search tabs and Stackoverflow.com. What's on their terminal? One tab usually has a man (3) page up for shmemget() or something. A lot of what we're doing is looking up documentation for an API. I don't understand how this is somehow more "pure" than having that same documentation browsable in your editor and at your fingertips!
You're right; IDEs encourage lazy programming habits. But look again at that guy fumbling around with his mouse. Is he REALLY going to turn into a ninja command line wizard because you took his IDE away? Nope. He's going to continue to be mediocre no matter what tools you give him, because the underlying reason is deeper than the tools.
Nonsense. You know what's lazy? Working on a project with millions of lines of code and deciding that digging through it to find the routine you need is more work than just coding it again.
My conspiracy theory is that editors that allow you to enter code real fast encourage a personal not-invented-here syndrome. Coding it yourself is faster than looking up how to use someone else's code (be it code by a team member or an open-source library). If the only way to use a lib is to read bad reference docs on the internet, or, god forbid, the source, and you're on vim/emacs/sublime, then sure, hack it together yourself. It's faster, more fun, and all the trouble caused by code duplication and added complexity is for your successors anyway. Not your problem! This why all PHP, Ruby and Python programmers build their own HTTP request router at some point in their career (I sure did).
On the other side, editors that make it very easy for you to discover and navigate code will encourage you to use existing code. Typing `someObject.` and getting a precise, documented and navigable list of exactly what you can do with that object. That causes you to use that object the way it was intended. Maybe refactor one of its methods so that it's more flexible or general. You wouldn't refactor a method that you don't know existed, right? Direct, at-your-fingertips insight in the code you use, and the code you wrote last month, encourages appropriate use of said code.
(Sidenote: of course there's absolutely no reason why an IDE can't have great text-editing keybindings. I suspect that the only reason most fakevim plugins for IDEs are mediocre is because the user group is so small. After all, the average vim/emacs user looks down on IDEs)
> My conspiracy theory is that editors that allow you to enter code real fast encourage a personal not-invented-here syndrome.
If your "million lines of code" project isn't well documented or designed, then relying on an IDE to find pieces of code doesn't really help.
It is also my "conspiracy theory" that because IDEs are so good at hiding the junk under the carpet, developers become sloppy and stop carrying about things like modularization and API design, immersing themselves into sloppy code and factories of factories. E.g. no project should ever get to millions of lines of code, because no developer is able to keep it in one's head, which is why monolithic code bases are a mess. If you're not splitting your project in multiple modules/libraries, you're doing it wrong.
And such users can't see it, because they are developing in languages in which IDE usage was encouraged from the start (e.g. C#, Java), so libraries are naturally developed with IDEs in mind, being really hard and frustrating to use them without an IDE, creating a vicious circle. It is also my opinion that IDE "users" (because seriously folks, many of you are not the kind of people that can adapt their environment to their needs, therefore you are just users) have never tried to develop in Vim or Emacs in combination with a potent REPL, plus the Unix toolchain. Unfortunately for you particularly, you'd also have to change languages and immerse yourself in the Unix culture for that to be a pleasant experience. But seriously, try it sometimes, you might just like it.
Note that I'm currently using IntelliJ IDEA, from the same guys that are delivering ReSharper, the plugin that makes Visual Studio usable. IntelliJ IDEA is a really potent IDE. But many times I hate it and I can't wait to get back full-time on Emacs, unfortunately I have to use IntelliJ because I'm dealing with Java's ecosystem right now. Well, at least Java has Maven and SBT.
But seriously, this is almost entirely bullshit. I've used IDEs for a long time, and they just don't encourage the problems you're describing here. Bad developers do, and that's totally independent of your language or your editor. Maybe you don't have to work on million line projects but lots of people do, and maybe, just maybe, it's not their fault and maybe, just maybe, there are totally valid reasons that their projects are like that. It is my opinion that mere editor "users" (because seriously folks, many of you are the kind of people who can't get off your high horse) never understand that, and refuse to accept that perhaps other people might like different tools or work in different scenarios than they do.
And yes, I used Emacs for 8 years. You couldn't pay me enough to go back.
Good points. How about "IDEs can encourage lazy programming habits, but that's more an indictment of the programmer rather than his or her toolset."
I've personally moved to Vim because I found that I like it, but I still have all the plugins that turn it right back into an IDE of sorts. I try to resist looking down on IDE users... I used IDEs for a long time and suffered no ill effects (that I know of).
The fundamental concept of "browsing" (a.k.a. discovering something new, rather than navigating to something whose existence you know of a priori) seems to be completely lost on the 'nix folks.
IDEs like Visual Studio with Intellisense tell you your options when writing code. Text editors fundamentally do not have that capability. The end result is that you spend a lot of time looking through code manually ("the code is the documentation", etc.) figuring out the right arguments to call a function with and such, when in fact the editor could have just told you what you needed to know right in front of your face with zero effort on your part. That's lost productivity.
I use clojure inside emacs fulltime now, but in a former life I worked with and liked Visual Studio, and I even owned Visual C++ 1.0 back in the day.
Visual Studio keybindings (even its emacs keybindings, whether or not they existing in 2013) are indeed pretty bad in places - as you note, it sometimes makes a distinction between the text editor and the UI widgets, so you do find yourself leaving home position regularly to move up and down a list, instead of C-n/C-p. But a lot of the problem is just people not bothering to learn what's available.
The IntelliSense has better defaults than you get with most emacs modes, which is possibly why people notice a difference (i.e. in VS you don't have to _do_ anything, it auto suggests, and completes on punctuation, and always pops up a lot of nice info, all out of the box). But I'm not sure there's anything there you can't achieve in emacs, depending on your language - certainly in Java with flymake and the eclipse compiler you can do some good stuff.
The huge gulf, for me, is with refactoring. Visual Studio with Resharper is vastly, vastly more intelligent, powerful and reliable than anything you've likely cooked up in emacs, even with semantic mode etc. And I think this unlocks a lot of productivity - sometimes a problem isn't just text, it's deeply tied to the semantics of your code, and in VS (again, I'm assuming nobody uses it without Resharper) you can be performing refactorings at a pretty high level without skipping a beat. In emacs, not so much. The degree to which that happens in your code is the degree to which you'll notice and become bothered by it.
Again, this is for OO languages. I would certainly like more refactoring power than I have with clojure today, but nothing that's so far above and beyond just day-to-day paredit that I've bothered.
It depends on what language you program in. For C++ dev, I find both vi and emacs to be of no benefit. The Editor + Debugger + Source Navigation + Refactoring features provided by Visual Studio + Visual Assist plugin are unbeatable IMO.
vi/Emacs' strength is text manipulation. But in IRL most C++ developers (on any platform) are NOT typing in reams of C++ code non-stop. I will often pause to think, look up documentation/reference books, maybe take down some notes or work out a problem on a whiteboard, or debug/step through code, etc. In short the vast vast majority of my time is spent away from the editor. Honestly I don't see how a C++ developer can objectively claim any time-savings with emacs vs a full fledged IDE like VS. YMMV with other languages.
Apart from VS I have recently heard some very nice things about Qt-Creator, but I haven't used it personally.
It sounds like your experiences are seeing people who don't really know the tool and / or the framework. To someone who knows both, intellisense (especially adding in resharper) can be a huge productivity increase.
Snippets are pretty much available in every language, and they are a good start. The key thing about the tools VS (and resharper) add is that they understand the code, to a certain extent. So you're not merely doing text based processing of the code, but semantic processing at some level. Every year it gets better and better. As you come to understand what it is doing within that context, you can really use it to fly while coding, especially while doing things like refactoring.
I pondered this a few years ago with some colleagues but it never seemed possible to get off the ground: real programmers, who consider themselves fairly good, using best practices, working on real, meaty projects, videoing _everything_ and making it public. Actually being able to see in detail how this stuff unfolds would be great for me.
You can sometimes follow along with ludum dare etc but that's mostly stuff hacked together quickly. I'd absolutely love it if top open source coders showed up live streaming their work.
That sounds like more of a problem with the average VS/Windows dev than of intellisense.
Surely you use autocomplete or typeahead in emacs, right? It's just about saving time.
Intellisense isn't "I dunno what I want so I'll wander around." It's "I know exactly what I want and want to type as little as possible." VS also supports Emmet/ZenCoding, which is an extreme example.
I'm a vim guy, but it's wrong to look down on IDEs as pure crutches. They're just tools. In the end, expressive power is conferred more by paradigm and language than editor.
In this case, IntelliSense gives you visibility into available methods and their signatures right in the environment. When working in a larger codebase (LLVM in my case), it's very helpful to not have to look up documentation. Then there are tools like ReSharper which you can think of as "higher-order editing" tools that understand the semantics of the code and use it as a basis for manipulation, rather than simply modifying the textual representation of the code.
Vim is great at manipulating text, but not as good at understanding the code. IDEs are worse at manipulating, but a bit better at the latter. For most things, I reach for Vim. For bigger code bases, I'm pretty happy in an IDE, as long as it stays out of my way.
It's worth noting it's pretty easy to setup good IntelliSense-style behavior for emacs, too. I often try to press people who are fans of VS on why they think it's the best and I have yet to see anything that improves on a well-configured emacs with CEDET, magit, etc.
I think it's the "well-configured" part. While I love using vim, my .vimrc file and .vim folder have been crafted and maintained over years. I can't give those to beginners without explanation. VS needs no setup. Intellisense is free.
I'm not familiar with Emacs+CEDET+magit, but if it has these features, then basically yes - its Intellisense is as good as Visual Studio's:
-Method and property completion on framework and own methods
-Parameter hints on all methods
-Enum completion
In addition, VS has a solution-understanding which goes way beyond intellisense. For instance I cannot fathom how people are able to work without "Navigate to definition", "Find usages" or "Refactor > Rename" in any development environment.
I use at least the first two on the list regularly in emacs; I don't have enum completion setup in C++ code, but it may be available or easily addable with some CEDET hacking. The big caveat that configuration is onerous, depending on the target language. I doubt that emacs's IntelliSense-like packages are as good as VS's, certainly in terms of polish and packaging, but what it has is good enough.
Also nice is being able to immediately pop up the man page for the symbol under the cursor, as well as language-specific documentation (like the Hyperspec in CL), and the ease of extending it to do exactly what you want, and supporting new languages, can't be beaten.
I refuse to work in an environment without jump to definition/references. These things should be considered a bare minimum requirement for a programmer's editor.
I've found that you can make Emacs and Vim be just as fancy as Visual Studio when it comes to all this stuff (and when you combine semantic intellisense with plain-ol' fuzzy search, you arguably get even MORE value, because you can do things like "build up an intellisense" by repeatedly calling methods on a dynamic object).
BUT, it doesn't work out of the box. You have to set up the plugins right, you have to make sure all the tools respect your compiler and library paths, in some of these environments you have to manually rerun your "tags" program for the editor to pick up the updates.
My point is that, even though all this stuff is getting better, it's still pretty far away from "just load stuff into Visual Studio and chances are you'll get a bunch of fancy stuff".
As someone who uses both VS and IntelliJ IDEA regularly, the latter is superior. VS with ReSharper comes close, but raw VS has comedic support for refactoring when compared with IDEA.
In my experience, if you haven't tried IDEA, it's best not to claim VS's superiority. I mean, just look at the ReSharper page. All of those things are missing from VS for C# but not IntelliJ for Java.
Frankly, the two are simply not comparable.
Edit: Rereading, this seems combative. It isn't meant to be. Just try IntelliJ if you're working with Java. It's really good. I hope its features come to other IDEs as well.
VS 2013 has IntelliSense support for TypeScript and AngularJS, although it does ask you to install the latest TypeScript plug-in. I'm using it full time and I prefer it over SublimeText, probably because I used to do a lot of C# and I'm used to the environment.
Is there anyway to get PHP intellisense in VS2013? I love me some Visual Studio, but since we do our web apps in laravel... I have had to abandon it for the time being.
On a related note, DevSense has also taken over development the Phalanger project (a PHP compiler/runtime for .NET). It's Apache 2.0-licensed and on GitHub if you're interested: https://github.com/DEVSENSE/Phalanger
I know you weren't asking for other IDE recommendations, but I thought I'd give you perspective from someone who is almost exclusively a VS user and loves the IDE (well, up to VS2010, or VS2012 with 2010 colors and icons).
When it comes to the occasional PHP project, I just use an IDE geared toward PHP development. Admittedly, it has been a while, but when I tried using PHP extensions for VS in the past, debugging, unit tests, etc... all seemed to require a ton of effort or didn't quite work the way I wanted them to. I would have loved to use VS for all development, but in this case, I felt like the tool was too weighty and not quite compatible.
In my particular case, I use Netbeans because it is free, lightweight, and it just works. My projects are more portable to other non-VS developers and adding PHPDocs and PHPUnit support was really easy. I'm sure there are other good IDEs as well.
I only wish Visual Studio retained the same MVCRT/MSVCP runtime libraries, or at least some backward-compability mechanism.
It really boils down to this - if you do plugin development for a product (Adobe's, Autodesk, etc.) or ffi-bindings for some language or environment, then you have to make sure you use the same CRT version as the host application.
And while statically linking to your CRT in your plugin DLL might work, it might not always - hopefully most people have found workarounds - for example not exposing "FILE*" or memory allocations/deallocations across DLL boundaries - e.g. alloc/free is done from the same DLL. But sometimes things like C++ exceptions make this even harder.
And now I'm seeing VS2013 brings yet another new CRT. Oh bummer!
I downloaded and installed VS2012 a few months ago, but I saw no reason to use that over VS2010. However, I downloaded 2013 two weeks ago, and now it is my favorite version. I'm thinking about uninstalling 2012, and I haven't used 2010 since installing 2013. Why? 2013 adds some really nice improvements: cursor position, line changes, and breakpoints are shown on the scroll bar; peek definition; Intellisense seems better; predictive typing everywhere. Having all these improvements out of the box without having to download third party addons is a nice touch. Microsoft should have had all these features a long time ago, but it's good that they are finally here.
I did the same with VS2010 and VS2012. The problem for me is that I'd have to buy MSDN all over again just to get VS2013. The features just aren't enough to plunk $1000+ down. I like it but, for single person devs like me, the cost is just too damn high.
I've been using it a couple weeks, and I really like it. Vast improvements in usability for me. It's mostly a bunch of little things that add up to a better experience. Peek Definition, Map Mode, support for Zen coding, MVC 5 goodness, and the list goes on and on. Lots and lots of little fixes that go a long way.
For everyone who thinks the cloud-based option is a good deal (Visual Studio Online), I have to ask:
-- You are paying $550+ per year ($45*12+tax) yet you don't own the software
-- What projects are you working on where, if the software locked you out (due to non-payment, error, server unavailable, etc), you would be okay with that?
-- Lastly, how secure do you feel the source code you upload is?
In the wake of the Adobe breach, it would seem that "The hackers accessed our users' source code, user details, and CC numbers." would be far worse than "The hackers accessed our old builds, user details, and CC numbers." In the former, I would think there are legal ramifications for many of you. For example, if you have a contract that states that you can't share source code with a 3rd party, yet you upload these files to MSFT (a 3rd party) and they get leaked, how will you protect yourself if a client files a breach of contract lawsuit?
How is uploading source code to a cloud IDE different than using a hosted VCS like GitHub or Bitbucket, which is also increasing in popularity? Also the people who are deploying to Azure are already trusting Microsoft with their source code.
And you're not owning the software even with a normal Visual Studio license. You just get the binary blob and a license to use it, not the source code. Using the cloud-based version, you don't get the binary blob, but does that make a difference?
All improvements are much appreciated. The only problem that gets worse at every release is Visual Studio's context menus. They are getting more bloated everyday and that is a PITA.
They[1] say it's been resolved in 2013RC, but I don't see much improvement specially when you add the now-almost-standard extensions such as WebWorkbench and WebEssentials.
Question for anyone that has used vsvim and ViEmu (the commercial product).
I have ViEmu for older version of Visual Studio and looking at purchasing the new version.
I am thinking that I can possibly get by without ViEmu and just use VsVim the free extension. I don't particularly use all the advanced features of ViEmu.
Haven't tried ViEmu, but vsvim is actively maintained. Lots of fixes have gone in to making it play more nicely with other plugins like ReSharper. Compared to vim emulation plugins in other editors like sublime text or even emacs, vsvim provides some pretty good coverage of vim features. Don't expect vimscript support or anything - the modes are pretty good though.
I just migrated lots of my project to vs2012 from vs2010 ... why should I go to vs2013 ? I've got resharper et deamon installed, and I really like my IDE like this ...
Considering new short release cycles do what you would do with smartphones and tablets - just skip a cycle. 2013 feels like fat SP rather than a new release: no new WPF/etc., just some Azure and Win 8 crap. And MVC 5 is now a separate release.
I do agree with you but nowadays you could pickup a used Mac Mini for $400-$500 that should be more than good enough for this. It's still a cost but its not as out of reach it may have been.
