At this point I really have no idea how much of the awesomeness I see in Visual Studio is coming from ReSharper and how much is actually Visual Studio itself. In the past, it was nearly 100% R#. Now it seems more like 50/50.
The only way I ever find out is through blog posts like this where they announce "new" features that I'd already been using for six years such as the "introduce variable" and "extract method" refractors mentioned here. Evidently that was ReSharper.
Makes me think I should go read up on what's new in R#. I bet there's a bunch more cool stuff that I'd never learn about until VS.NET 2020 if left to my own devices.
It's often the case that if something along the way is null, breaking the reference chain, it's acceptable to treat it as if that last value were null. E.g., looking up a preference that enables some optional behavior on a module, but the module itself is also optional and might not be loaded.
I really can't even count the number of times that I've done a series of null checks on a reference chain just to do one thing if I reached the final value and another thing if I never got there or got null - It's pretty rare that I'll care about an intermediate null, and if I do I've usually checked it earlier.
I'm hoping they move CodeLens from being a VS Ultimate only feature to the lower editions (Premium maybe?) in '14' as it looks really powerful but the pricing on Ultimate is pretty far outside of most developers' reasonable expense range.
Seems there is significant demand on this but the UserVoice ticket was closed in April this year.
I never really understand the argument against Microsoft software being out of the range of reasonable expenses.
Certainly for all the corporates I have worked at, Ultimate is well within their budget.
But Ultimate really comes with all the bells and whistles. If money really is an issue, and you find you must "Collect and analyse runtime diagnostic data from production systems" or "Reliably capture and reproduce bugs found during manual and exploratory testing to eliminate "no repro" bugs" then there are better tools out there.
I've worked for a long time with Premium[2] and never felt like I was missing features...
I think it's more that CodeLens appears to be far less of a niche feature than the others exclusive to Ultimate, which has people up in arms a bit because it looks universally useful to all developers (but not useful enough on its own to justify the extra $10K or so if you're not using other Ultimate features).
We have MSDN access here, but that only offers Premium, not Ultimate.
So yeah, I run Premium day-to-day also, but I definitely feel like I would benefit from CodeLens in my dev workflow (especially with the upcoming Git integration in VS2013 Update 3).
I think so because Windows XP POS has support until 2019 and businesses still need to develop POS apps for their embedded POS systems. Even if the consumer XP has dropped support the POS version of XP has not yet.
Too many ATMs and POS systems that still run XP, give them until 2019 to switch to Windows 8 POS systems.
(Speculation, I haven't actually installed VS14 and side-by-side is not supported so I couldn't test this anyway.)
It's probably gone but the toolset targeting is likely still around. So if you've VS2013 installed with the XP-compatible compiler and Windows SDK then you can just choose that toolset.
Usual disclaimer applies: it's an old compiler, you won't get the new language features etc.
14 is not the public (marketing) name, it's our internal version number. The currently shipping version, as you note, is version 12 (internally), but is called Visual Studio 2013 on the box. There is not necessarily a relationship between the version number that is used internally and the version number as described my marketing.
I don't think we've made any public statements about "why 14", but I'm sure that you can draw your own conclusions as to why we jumped from 12 to 14 without a 13 in the middle.
(ObDisclaimer: I work on the Visual Studio TFS team.)
If they skipped the 13 out of superstition, they should also skip 14, it doesn't bode well in Asia where in some countries, buildings often don't have any floor numbered 4, 13, 14, 24... not that these floors don't physically exist of course, these numbers are just not used.
I really like visual studio as an IDE, but I find myself really liking some of the things in 14. vNext, removing the cruft from my current stack, Rosyln at it's least simplifying the difference between my intelisense and actual compile.
But as you are on the TFS team I feel you are a good person to ask, are there many improvements from a TFS source control perspective? It still feels 'clunky' if I want to commit and run a specific build it's laborious. Oh and lets not even ask why my visual studio online builds, with their paid azure account haven't built anything in the last 5 hours :(
I do like the ecosystem, I like an IDE that lets me do everything in one place, that is extensible enough to ensure I can od everything I need there. But the current interactions, maybe tonights downtime has made me angry, are rather disappointing.
From a version control perspective, we're investing heavily in Git right now, which brings a DVCS ecosystem into Team Foundation Server. This means that you can choose between using a checkout/edit/checkin model (TFVC "server workspaces"), a much more relaxed edit/merge/commit model (TFVC "local workspaces") or a DVCS (Git). I hope that wasn't too marketing speak-y.
Anyway, sorry things feel clunky. I would definitely suggest moving from a server workspace to a local workspace if you haven't already and don't need some of the guarantees it makes about locking files for checkout and such. An edit/merge/commit system isn't nearly as chatty with the server and is much more pleasant to use on a daily basis.
local workspaces are hopelessly broken for repositories of any real size. They're slow, you get local store conflicts when running multiple copies of VS, etc. Server workspaces are a pretty poor solution if you have remote workers on poor connections.
So far Git integration seems good, but I have only used it on some smaller projects.
Here's a moaning email I sent to a few devs I work with in April re: TFS:
"...In the office it's slightly better, but TFS is still slow. This is just the tip of the iceberg with TFS though.
Open TFS explorer - 20-30 seconds
Open a folder in TFS explorer - 20-30 seconds
Rename a file - forget it, go and get a coffee
Add a file - forget it, go and get a coffee
Delete a file - forget it, go and get two coffees
Edit a file - Often I see "Waiting for a required operation to complete..." -- see below
Then when you add into the mix that I'm on Virgin media who are the shittest internet provider on earth and who clearly do traffic-shaping on VPN connections; and they constantly drop my VPN connection, which will cause TFS to lock-up -- you might start to see why I'm going slightly insane.
Yet when I work on a pet open-source project with Git everything is sweetness. It seems like the Visual Studio team just started again with their Git integration. It doesn't even have to reload projects when you sync and a project file has changed, it just happily merges it in.
Ultimately even if we host TFS on the best server known to man, I won't ever get over the fact that Virgin media are going to be constantly fucking me over. So a local-store makes much more sense. TFS has a local-store mode, but (incredibly!) its performance is worse than the server version. It seems to be because our store is too large for it (over 100,000 files).
I think it just goes to show how awful TFS is if they can't even create a local database which can manage 100,000 files.
I see this error all the time (on VS 2012 and VS 2013):
[Picture of the 'Waiting for required operation to complete dialog']..."
Sorry if I'm bitching about your work, but it seems the Git integration is the only real game in town right now. It really is very impressive compared to the other options.
Unfortunately I can't really provide advice for your local workspace troubles as I work on the Git side of things.
I'm sorry to hear about your performance troubles with local workspaces: 100,000 files in a local workspace should not be at the upper limits, I wouldn't think. Many people 'round these parts were using local workspaces for their VS 2013 development: my working folder mappings appear to be 25 GB and 120,000 files for VS 2013. Concurrency and locking, of course, could affect that, but I'm still surprised.
I trust you're not doing anything wacky like trying to put your working folders on USB sticks or SMB mounts, so I would recommend either opening a question on the MSDN support forum or (better) opening a support ticket. Our support engineers are really quite good and might be able to assist, or at least understand why you're seeing this performance with local workspaces.
(I regret that we cannot fix your internet provider.)
Heh, thanks for the response :) I realise you can't do anything for me, I just thought I'd give you a sense of the frustration of the local-workspace route. The fact it's slower and less reliable than the server-workspace approach is pretty crazy.
> I trust you're not doing anything wacky like trying to put your working folders on USB sticks or SMB mounts
Nothing crazy, repository is sitting on an SSD drive.
If you're working on the Git side, then all I can say is: great job! I'm hoping to move our source repository over Git soon... I can't handle staying with server/local workspaces much longer, but as with all things like this it's about finding the right moment for the team to switch.
I can't use VS 2013 because the GUI crashes frequently. For example, tasks like creating a new project through the wizard crash. I would like MS to fix these issues before moving on items like C++14 support.
Personally haven't had any of such problems actually on none of my machines and I can't wait until they get certain C++14 features in (generic lambdas! user-defined literals!) as they will make my life as a C++ programmer not only easier but also more fun. Seriously, working with variadic templates etc makes me feel like some wizard in control of Mordor. Bring it on!
Both as a user and a Microsoft employee, I'm happy to have minimal secrets and surprises when it comes to dev features. Early info and access usually means better software.
>"Installing a CTP release will place a computer in an unsupported state. For that reason, we recommend only installing CTP releases in a virtual machine, or on a computer that is available for reformatting.
>Currently, Visual Studio "14" CTPs have known compatibility issues with previous releases of Visual Studio and should not be installed side-by-side on the same computer."
I don't know how serious that statement is, or maybe it's just a big blanket clause. But it seems like they really, really think you shouldn't install them together.
Those who made the mistake of installing pre-releases of VS2012 alongside other versions got burned badly. In general Microsoft pre-releases of VisualStudio are so bad that we've resoved to installing them only on VMs. Some who didn't had to resort to reformatting their drive and OS.
I think they give you a key by registering for 90 or 180 days to evaluate it and try it out for free. Make a virtual machine in Vitualbox.
I choose Virtualbox because it has a GNU/Linux and OSX version, unlike VirtualPC so you can run virtual machines on GNU/Linux and OSX systems.
Some people like VMWare, others QEMU, and some use what Microsoft has. But Microsoft has these evaluation ISOs for free for a limited time so if one runs out, just reformat and reinstall it in a virtual machine to test it out.
From the one screenshot that shows window decorations, it looks like they're keeping those broken where they don't match the rest of your windows and don't change color to indicate active vs inactive?
I have multiple monitors and tend to have several programs open. I like knowing where my input focus is.
Despite the down votes I stand by what I said. I would be far more impressed with a stable version of vs 2013 than a preview of 2014. There are too many glitches to document here, but I am using it every day and constantly finding bugs, some of which I have reported via Connect, some I can't be bothered with.
I tried to up-vote, but I think the folks from MS are getting home. I got the same problem, and it killed my migration plans and inheriting constructors.
Thank you. And don't get me started on vs2013 update 2. I wasted a day putting up with it but eventually had to uninstall out of frustration. After that experience I can't see myself ever installing update 2 unless there is a showstopper bug in update 1.
2. I use ctl-shift-f a lot where I double click the matches and it takes you to the code windows. That always stops working after a few hours.
3. Web service in a solution no longer spin up automatically. I have to start them manually everytime I open VS. Combined with point 2 is extra annoyance.
4. Connecting to Azure via Server Explorer -> Windows Azure -> Connect to Windows Azure requires me to first go do some other random thing otherwise I get a non-nondescript 'network error'
5. I upgraded to update 2 and it quietly turned a number of crucial references to 'Copy local = false', which didn't stop the app working on my machine because I had the sdk installed of the relevant library, it only broke on test machines.
6. Not that I use it much, but yesterday I noticed the WPF designer randomly stops me from changing simple properties such as margins. It works for some properties and not the others.
I like metro better, with its full-screen/tiled modality, and find it really frustrating as well as unaesthetic to have to switch back and forth to the desktop. If Microsoft's own apps won't make the switch, it seems like they'll never manage to get rid of the desktop.
I think the complexity of software development warrants a pass on the switch to Metro. There are so many things going on that can't be simplified that it's not worth it.
Also, Microsoft doesn't want to kill the desktop. Enterprise uses the desktop, so it's staying for the foreseeable future. Full stop.
Is there any reason applications with complex functionality can't be written in Metro? And if Microsoft isn't trying to kill the desktop, why does it exist as a separate world in Windows 8 severed from the main Metro UI?
Metro exists separate from desktop because they couldn't figure out how to make the desktop work on a touch-centric interface like tablets and phones, and because desktop apps are bound to x86, which precludes many phones and tablets because of battery life reasons.
I don't want to run Visual Studio on my phone. But if I get say a Surface Pro device, I'd like to not have to switch back and forth between two totally different worlds all the time, without giving up modern amenities like resolution independence, etc.
That is why people want to stick with XP/7 instead of 8.X because they don't like the Modern GUI (It was called Metro until Microsoft was sued over the name) and feel like it is a giant step backward to the 1992 MS-DOS days of AOL for DOS or the old Prodigy of everything in small Windows that you cannot even re-size or have any 'visual clues' how they work like the Desktop and Start Menu of the Classic Windows has.
For example 'visual clues' in the Classic Windows have minimize and maximize buttons and the "X" button means close. These Modern GUI Windows, where are the 'visual clues'? It breaks the way Windows is supposed to work.
You have to drag the mouse to the bottom or top right side of the screen to access the 'Charms Bar' to do stuff in it, and Windows-C as a shortcut. I tried the touchscreen and it is a nightmare trying to make the correct type of swipe. Sometimes it does things you don't want it to do.
Plus a lot of desktop apps cannot be converted to Modern GUI mode because it lacks the gadgets the desktop has to make things easier to use. The Visual Studio IDE for example has so many tool icons and toolbars that not all of it will fit in a Modern GUI screen. It would need a major rewrite of the GUI, and force all developers to relearn all of their Visual Studio skills.
Remember when Office 2007 made that Ribbon bar? It was worse than Clippy the Office Assistant type of annoying.
Many compared Modern GUI to New Coke, the Classic Version was always better. If not for Desktop mode I could not use my Windows 8.1 Pro device.
Modern UI isn't ready - that's why so many people hate it. How do you make desktop better? It is already perfect. But development must go on - there is a need to make something new that people would buy.
So, you start a new thing and add continuously "new features" that are simple and elementary as hell. Years of safe development of elementary features that may simply be included in the first version of software - but they aren't. In Windows 8.1 you don't need to stick with static background colors. Wow, what an update and development achievement. Couldn't foresee that user would like that.
I think that Modern UI becomes more and more user-friendly but it takes time because you simply cannot make final product with first version because then the next versions wouldn't shine.
I found it usable for 90% of the use cases but that last 10% is incredibly frustrating. It's been a long time since I've used Office so I can't conjure up an example but I remember trying to do something with tables that was fairly straight forward in Office 2003 it was nearly impossible in 2007.
I agree; they'll never get rid of the desktop. Certain classes of software, such as those based around an MDI, will never have a home in the hyper-focused and single task-oriented world of Metro (and iOS for that matter).
Why does Visual Studio need MDI? XCode and Lighttable and Sublimetext get by just fine with panes, tabs, and dividers. I could totally see say Lighttable being a Metro app.
Speaking personally, due to the massive size of modern screens, the only application I run full-screen any more is my video player. Metro is a non-starter for working with multiple overlapping windows.
I normally develop with at least 6 windows in frequent use - two browsers (one for doc / misc and one for app) and 4 terminals (two for simultaneous login to front and back nodes, one running the app along with mysql sessions, and one running emacs).
The idea of using a single full-screen dev environment, or perhaps with one other window docked to the side, seems ridiculously inefficient. I need to see those other windows. I'm frequently tailing logs, running tests in the background, provisioning VMs, all little things that need to be visible so I can see when something goes wrong and I need to take action.
Of Xcode, LightTable, and Sublime Text, all three of them support opening code in new windows in addition to in panes, tabs, and dividers. So their popularity is not evidence of MDIs being unnecessary. Whether their MDIs are necessary depends on how many people use multiple windows in those apps, and would dislike using other views if multiple windows were not an option.
alt-shift-enter, go fullscreen, ditch the windows chrome. I don't understand how you would want a Metro UI for vs.net - such a waste of screen real-estate!
Off topic: Have you used this at all? If so what's your take on it? I've heard about it and that's pretty much it, but got the gist that it's more of a "toy" development environment than anything else.
From the blurb "Building a Siena app is as easy as editing a PowerPoint presentation or Excel spreadsheet. You place some visuals on a canvas. You hook them up to your data or favorite services. You customize how your app looks and works. Then, if you need special logic and intelligence, you write some Excel-like expressions. You can use your app immediately, or share it with colleagues or the world."
So aimed at non-programmers but with some modern stuff like the ability to talk to restful services.
VS2013 introduced a lot of C99 (enough to compile FFmpeg), VS2013 update 2 introduced more C99 (compiling almost x264 and a bit further VLC). This update adds some of the biggest issues, related to printf and scanf formats, and fixes more C99 reported bugs.
From the VC++ blog: "Most of the remaining C99 library features are implemented."
I love to hate Microsoft like the next guy, but they've done a lot on C99 lately.
"Visual Studio "14" also supports APIs that come from NuGet with their own analyzers, squiggling issues in your code as you type and offering you automatic fixes, all powered by the .NET Compiler Platform."
So, now there's new stuff that will keep me from typing into the IDE without hanging up and causing delays.
The only way I ever find out is through blog posts like this where they announce "new" features that I'd already been using for six years such as the "introduce variable" and "extract method" refractors mentioned here. Evidently that was ReSharper.
Makes me think I should go read up on what's new in R#. I bet there's a bunch more cool stuff that I'd never learn about until VS.NET 2020 if left to my own devices.