Visual Studio 14 Preview | Hacker News Reader

Visual Studio 14 Preview

blogs.msdn.com

140 pointsPermit100 comments

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.

My recent R# discovery is that JetBrains.Annotations is like a lightweight version of Microsoft Code Contracts.

Extract Method dates back to at least VS 2010 however introduce variable is new.

Looks like VS 2005 had it:

http://msdn.microsoft.com/en-us/library/yez2fsct(v=vs.80).as...

According to http://blogs.msdn.com/b/csharpfaq/archive/2014/06/03/visual-... it's also gonna have ?. operator! Woohoo

I'm on the fence about this. From the example, `myObject?.Items?.[0]?.DoSomething()`.

If myObject, Items or Items[0] returns null, what do I do next? Null check to find out which one?

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.

If you need to know which one returns null, then do it the standard way.

Looks interesting.

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.

https://visualstudio.uservoice.com/forums/121579-visual-stud...

Have you seen the Bizspark program?[1]

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

[1] http://www.microsoft.com/bizspark/faqs.aspx [2] http://www.microway.com.au/microsoft/visual-studio-2013-comp...

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

CodeLens - Yes, I see, you make a fair point...

Has Microsoft stated whether they intend to keep the WinXP-compatible toolchain around? I imagine they won't now that XP is officially discontinued.

Then again, Windows Server 2003 is still hanging around until next year, so maybe they won't ditch that compiler just yet.

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

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.

I don't think they are going to keep XP support for that reason alone though.

This version of Visual Studio still seems to have XP support.

Visual Studio's naming scheme is pretty strange. They'll release this version in 2015 and the Visual Studio DLLs were previously on version 12.

So it'd have made sense to name it Visual Studio 2015 or Visual Studio 13, but they opted for 14.

The number 13 seems to get skipped for superstitious reasons.

If a software engineering company has superstitions then I wonder about their engineering capabilities.

Probably a management decision, not an engineer one.

Yeah. And don't get me started on all those construction and elevator companies that skip 4th and 13th floors. Brrr.

See here: https://twitter.com/jongalloway/status/473912144761602048

That's what I've been told. I am often wrong and / or misinformed.

Soma's blog states 'Visual Studio "14" will most likely be available sometime in 2015'.

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

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.

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.

Tretraphobia it's called, and it's a serious thing: http://en.wikipedia.org/wiki/Tetraphobia

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!

The Roslyn stuff is going to be really awesome. It will be interesting to see what types of refactoring and code analysis tools the community creates.

Kind of wish F# was in scope for the Roslyn project

F# is already a bootstraped compiler, which was the main driver behind Roslyn.

Yet still no automated refactoring. F# team likes to develop the language and the compiler but they have no interest in practical tools.

I guess it is a matter of resources and internal priorities.

They do however work in some tooling support

http://fsprojects.github.io/VisualFSharpPowerTools/

Seems to mostly be a packaging of features we already knew about, but it's nice to see them trying to keep with the faster release cycle.

The release schedule's been that way since ~2012: http://www.visualstudio.com/en-us/news/release-archive-vso.a...

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.

What a pity that you cannot install it side by side with other version of Visual Studio. Well that means I will have to setup a VM for it :D

I don't think it's that you can't install it side by side, they simply don't recommend it while this is in beta just in case.

"Given that this is a very early build, please install in a test environment with no earlier versions of Visual Studio installed."

I had a brief moment of panic thinking that this version wouldn't co-exist with others after reading your post. :)

From the actual download link

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

I think they always say that for the Betas.

As a matter of fact, i actually got blocked by the web installer. It denied installing it sire by side

It modifies system files like the Kernel and other stuff. Files that cannot be updated after the beta expires.

http://www.virtualbox.com/

That's what I use, you can find the Windows 8.1 Ent Evaluation here

http://technet.microsoft.com/en-us/evalcenter/hh699156.aspx

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.

Why would an IDE need to modify the kernel?

And how does the VS team even get the signing keys to ship a new Windows kernel?

Perhaps it "modifies the kernel" using kernel drivers? I agree, it is a fantastic claim.

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.

Can't wait for the new runtime dlls

lol

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.

Chrome of active and inactive VS windows looks different in all VS versions. In 2013 the difference is just in the caption color, but it is there.

This is not the case for the one I have installed here at work, which is Professional 2012.

I have both 2012 and 2013 on my machine, 2013 changes caption color, could not see anything on 2012 change.

I am annoyed by this. Vs 2013 is riddled with bugs but they are busy doing the next version?

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.

What's your dev environment? If I've ever had a problem with Visual Studio it always is some type of add-on.

I've been using it for years and have never had a problem.

You deserve the down votes because all you've added is emotion with zero content.

Why haven't you mentioned a single specific bug? If there are too many, tell us about the ones that you think are show-stoppers.

I don't have much time, but firstly :

http://connect.microsoft.com/VisualStudio/feedback/details/8...

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.

What are you even doing with it? I only had one issue so far with the Web Essentials extension after installing VS 2013 Update 2.

Any hope of a Win8/Metro version?

Why would you want a Metro version? (I'm really curious, not just hating on Metro.)

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.

But why have the schism on desktop devices?

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.

Modern UI applications do have a minimize and close button now. They also show up in the taskbar.

I find the ribbon to be very usable

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.

Have you tried working with desktop apps on a touch-centric interface?

It works great. I don't use any Metro apps on my Surface Pro. Click, Double-Click, Drag, Drop, Right-Click - it all works very, very well.

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.

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.

Visual studio does definitely allow that, although I honestly don't use it very often.

Apps with tabs are MDI - VS uses tabs for MDI.

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.

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!

Very doubtful. They don't seem to be pushing productivity apps away from the desktop interface.

That would be unlikely, as discussed in other comments. But see Project Siena for a Microsoft app-building app that is Metro

http://www.microsoft.com/en-us/projectsiena/default.aspx

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.

--No offense meant by "toy"--

No, havent tried it, just seen it in the store.

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.

You can just hide all the menus and buttons and put the editor full screen. That's pretty close to metro I think

Pretty absurd still no C99 and C11. Luckily Windows continues to slip in relevance.

Sorry, but what is missing from C99 in MSVC?

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.

Probably variable length arrays and flexible array members, at least. Could be wrong.

VLA will not be in VS, since it is now optional in C11.

Flexible array member, I haven't checked yet.

Hexadecimal floating-point literals

In what context?

In the same context as "normal" decimal floating-point literals, e.g. double x = 0x1.ABCDEFp+89;

It's an afterthought, usually brought in as part of the C++ standard du jour. We'll be lucky to see C11 in 10 years.

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

Ummm... So don't download them?

The new anaylzers use async, so it's happening in the background as you work. For example, symbol analyzers take an action delegate with a cancellation token: http://source.roslyn.codeplex.com/#Microsoft.CodeAnalysis/Di...

Reply on news.ycombinator.com