Visual Studio 2017 Release Candidate | Hacker News Reader

Visual Studio 2017 Release Candidate

visualstudio.com

289 pointsjpalomaki118 comments

As a .NET dev, I'm happy to see this:

"a new way of view, edit, and debug any code without projects and solutions"

Seems silly, but this solves a long time gripe w/ VS.

Good for small scripts in python etc I guess? Otherwise, when would you want the IDE's abilities but constrained to one file?

You aren't necessarily limited to editing single files without project files. Lots of projects are folder-based with tasks or commands to be run on that folder structure.

See: Rails apps, Hugo websites, anything written in Go.

Right. Directory-based projects were there from the early days of Unix and C, even before make and makefiles organized things a bit.

>Good for small scripts in python etc I guess? Otherwise, when would you want the IDE's abilities but constrained to one file?

There could be valid cases, including other than small scripts in Python. I recently saw someone on the D forum (forum.dlang.org) write in reply to someone, that he did not want to be bothered with creating a DUB project, while he was in the early / experimental stage of some project he was working on. He said, just using:

dmd file1.d file2.d ... filen.d

was faster and let him focus on the main work, the code itself.

dmd is the Digital Mars D compiler, like (g)cc/cl for C (Linux/Windows).

(DUB files are something like makefiles, but specific to D, though D can work with make and makefiles too)

I've thought the same and done likewise sometimes, in C, for example, and in D too. For small projects and in initial stages, one may not want to take the time to define a makefile, may instead just prefer to do (in Linux):

cc -o prog prog.c ...

And likewise in Visual Studio on Windows. But may still want the IDE's abilities such as Intellisense, debugger and suchlike.

Visual Studio "15" = Visual Studio 2017 = VC 15.0 Crystal clear. Why didn't Microsoft bump up VC version to 17 to sort of make VC version follow VS version. Would clear out some confusion going forward.

The naming has been awful with this release in particular. Having two Visual Studio (20)15s out at the same time is very confusing. Almost as bad as the Skype vs Skype for Business marketing boondoggle.

There's some sick bastard in Microsoft who really likes these confusing sames. He's probably the same guy who came up with .NET.

Remember when .NET could refer to virtually every product Microsoft made?

I was half expecting them to call it Visual Studio Surface. Then you could run Surface on your Surface on any Surface on the planet.

Indeed, .NET must be the worst, most misleading, least googleable product name ever. I suppose we should be grateful that MS called an earliest technology COM not .COM.

I must say Google handles it well. I'm searching with these terms quite often and Google knows .NET == dotnet ~ C# and finds results without much problems.

Google is terrifyingly good at finding relevant developer documentation. I'm convinced it will be writing software for us in a couple years.

The first result I get googling for ".net" is the Wikipedia article ".NET Framework". The first result I get for "COM" (or "com") is Microsoft's page on "COM: Component Object Model Technologies".

Honestly, I have never had a problem googling .NET and COM-related stuff.

It was mostly a problem when you were having a conversation with someone that went something like...

"So I was installing .NET and it failed because I didn't have the right drivers for my SCSI card."

"What? I've never needed disk drivers to install .NET, which version was it? 1.1?"

"No, it was 2003"

or...

"Can you install .NET on my PC?"

"Sure, done"

"Where's Word and Excel?"

"What?"

This is after it became popular, and Google (I assume) just special-cased it. Back when it first came out, though, typing that into any search engine we had back then would mostly just give you tons of domain names that end with ".net".

Then also, we had Office .NET, Visual Studio .NET (with Visual Studio .NET 2003 added later), and pre-release versions of what was to ship asWindows Server 2003 were known as Windows .NET Server for a while.

Web services (the SOAP and XML kind) were the next big thing back then, at least as far as Microsoft was concerned, and so the entire software stack was promoted as conceptually centered around that - hence the .NET name. Kinda ironic, what with the rise of cloud computing later, when .NET brand was already toned down to refer to the framework specifically, and the consequent need to invent "Azure".

Back then I just used MSDN.

It could have been worse. The original internal name for .NET before the rebranding was COM+ 2.0, if I remember correctly. You can still see some legacy of that in names like COMPLUS_ZAPDISABLE (an environment variable that disables loading of ngen'd assemblies by the CLR).

Somewhat more indirectly, it also surfaced in low-level native APIs used to host CLR inside an app, with names like ICorRuntimeHost - if I remember correctly, COR here stands for Common Object Runtime. Also seen in mscorlib.dll (the assembly containing the most fundamental types, which is the top node in any CLI assembly dependency graph) and mscoree.dll (EE = execution engine).

Oh, and C# was COOL (C-like Object-Oriented Language).

> confusing sames

I can't tell if that's a typo or intentional. I might start calling them that.

I am at my cleverest when it's completely by accident.

On the other hand if you want an SQL server how does MS call it? SQL Server. Unlike for AWS you don't need a glossary to get around in Azure. (At least less so) This is why this disparity in naming thing very simply and straightforward and mind-boggingly badly is incomprehensible for me.

Ah yes Office .Net.

Such confusion. They then went and tagged "Live" on everything.

I am beginning to think that Microsoft's bad verison naming is entirely on-purpose.

Windows has had terrible naming since NT -- back and forth between names/numbers/years (or nonsense like "Anniversary Update" or "R2"), have a completely different scheme for Server vs Desktop, and if you look at the corresponding kernel versions of these releases[0], the major/minor bump in versions seems completely arbitrary.

.NET is even worse. Framework vs CLR is a mess [1]. Core started over at 1.0. .NET Standard brings some consistency to it all, but also introduces another versioning scheme with overlapping numbers that mean different things[2].

But even other divisions do this: Xbox -> Xbox 360 -> Xbox One.

[0] https://en.wikipedia.org/wiki/Windows_NT#Releases

[1] https://en.wikipedia.org/wiki/.NET_Framework_version_history...

[2] https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introduci...

You forgot about Windows 9. ;)

Was meant to have been skipped because it was too similar to Windows 9x (Win95, etc...).

Which wouldn't have been a problem if they followed a consistent naming convention in the first place...

On purpose... but any guess as to why?

Windows 2000 = 5 Windows XP = 5.1 Windows Vista = 6.0 Windows 7 = 6.1 Windows 8 = 6.2 Finally, they have Windows 10 == 10

No, 2017 written as separate numbers are 2 0 1 7 and adding them up gives 10. Half of 10 is 5 (obviously) and that sum is 15. Get it?

or perhaps 0 is some kind of infix flip-subtract operator

a 0 b := b - a

Call in Ramanujan. He'll surely come up with a good explanation.

https://en.wikipedia.org/wiki/Srinivasa_Ramanujan#Hardy.E2.8...

"No! It is a very interesting number. It is the smallest positive integer that Microsoft have not yet used as a version number."

Actually that would be 13.0!

This is what happens when marketing determines your version names.

Many software packages have poor or confusing version numbering. Java, IIRC, jumped from Java 1.2 to 2 or 1.4 to 4 or something like that. Windows 3.1 to 95 to 98 to Me to NT (stood for New Technology, ha ha [1]) to 2000 to XP to Vista to 7 to 8 to 10 ... (might have got some of the order wrong there).

[1] New, as in the classic marketing/advertising phrase "new and improved", maybe ... :)

NT was called "New Technology" literally because it was a new technology. It was based on the NT kernel (which is used now) as opposed to the 9x/MS-DOS kernels used in 1.0-Me.

Also, NT came before 95. Specifically, as Windows NT 3.1.

>NT was called "New Technology" literally because it was a new technology. It was based on the NT kernel (which is used now) as opposed to the 9x/MS-DOS kernels used in 1.0-Me.

Thanks; I was aware of that when I wrote my comment that you replied to. I was around in tech when NT was released, so I had read the expansion of the acronym then in the media. In fact I had read the book Inside Windows NT (the one by Helen Custer, a good one) some time after it came out. Remember it talking about Dave Cutler as the main NT architect, his DEC VMS background, etc. And it had a fair amount of interesting content about NT internals. Also remember trying this Linux C utility that I wrote, selpg (which I posted about in this other recent HN thread - https://news.ycombinator.com/item?id=12960242), on Win NT, because I had read that it had a POSIX subsystem (then and for a while). And it worked on it, including the POSIX popen() call (though not to an lp command, since NT didn't have a UNIX-like lp subsystem). My point in mentioning marketing was that even if Windows NT really was new technology (and it was), giving the name "New Technology" was somewhat unusual (after all, any non-trivial product upgrade is usually new tech, unless only cosmetic) , and so I thought it might have been the marketing folks's decision. And we know that marketing people do sometimes push product names for marketing reasons, that tech people might not always agree with. That's all there was to it.

>Also, NT came before 95. Specifically, as Windows NT 3.1.

I did clearly say above:

"(might have got some of the order wrong there)."

Even the MS installers get this mixed up sometimes. Sp5 to vs 2015 mixed up some paths between vc12 and vc14.

It's just a product with a name that has a year in it, but the executables inside each have their own different version.

For example for Visual Studio 2015, the visual studio executable is at version 14, and the C++ compiler is at version 19.

So would you also suggest changing the C++ compiler version back to 17 now?

The new installer is nice. Installed just a C++ environment in 5 minutes!!

Wow that's huge. My last VS2015 install took hours.

I usually do it at the end of the day, and leave it running when I end work.

Not even an option in the Windows 10 era, where our computers might reboot at any time on short notice. (work computers with group policy tweaks are something of an exception, but still)

Indeed. Plus I really like that I can install just the C++ tools and not all the .NET languages as well as I don't need or want those! The overall IDE speed is greatly improved as well. Looks like a good update so I am looking forward to the final soon.

That sounds awesome. Is there an offline installer yet ?

Yes - the release notes describes our initial capabilities on that front: https://www.visualstudio.com/en-us/news/releasenotes/vs2017-...

Essentially, you can run /layout on the installer to create an offline installation cache. We're working to add more capabilities here, but the fundamentals of the experience are in place.

Do you plan to package it to a sandboxed windows store app? Would it loose too much functionality that way? The garbage uninstalls left behind by earlier (and current) versions makes me think this might be a solution.

Having it installable via the store would be not only convenient, but also a good promo for devs to package their other legacy apps.

We have talked about it. Visual Studio is somewhat exceptional in its requirements, though: it chain installs other runtimes and platforms that update independently, it installs services and reconfigures the operating system (e.g. Hyper-V emulators), it updates system components such as the .NET Framework, and it installs privileged components like debuggers. On top of that, it offers a plug-in model with extensions that are updated independently of Visual Studio itself. So the Windows Store is not a viable option at this stage, although we are continuing to partner with our colleagues over in Windows to see if we can make progress on some of these challenges in future releases.

In the meantime we are leveraging other Windows technology to minimize the system impact of an installation. And the work we've done to rebuild our setup engine sets us up well for the future as the Windows store enables support for our more advanced needs.

Best wishes, Tim Sneath | Visual Studio Team

More importantly, how does the uninstaller work? Still tons of garbage left behind?

How many GB did it use?

Some first impressions here: https://blog.oz-code.com/first-impressions-of-visual-studio-...

Very nice overview! Thank you.

Wondering if the Live Unit Testing came from the acquisition/integration of the Alive project. Very interesting indeed.

It might be, but Alive was much more than just if the tests pass or not

Might be. Also, in any case - this adds stuff that wasn't in the original Alive AFAIK - supposedly it knows to only run tests that were affected by your last edit and show line-by-line red/green/gray coverage indicators: did someone say NCrunch?

Correct. Alive was focused on a chosen method - so you chose one method, the test case to check that method, and then it ran. You could then check what execution would look like in called methods, but it was not project/solution wide.

Thanks! I was hoping I would be able to get rid of ReSharper, but the lack of CamelHumps in navigation and in code completion will force me to keep using.

Personally they'll have to pry ReSharper from my cold, dead, hands - I've grown to rely on more advanced features like Value Origins/Destination https://www.jetbrains.com/help/resharper/2016.2/Code_Analysi... That I couldn't possibly go back.

Good God I love ReSharper. I've been using it since the mid 2000s. It's a wonderful tool. However, their more recent releases have introduced some pretty annoying regressions with code formatting and other features. They seem to be ignoring my hand-reported issues on YouTrack. I haven't been as impressed with ReSharper as in the past. Hopefully they can right the ship and put out better quality stuff.

Visual Studio already supports Camel Hump search in IntelliSense and for symbols within GoTo. It’s currently missing for file names in Go To, but we’re working on that and it should be coming soon.

P.s. I work on the extended VS team.

The whole Live Unit Testing thing sounds like they copy pasted NCrunch into VS

One of the install options is "Linux development with C++"

Yes our C++ team has been investing into this area for a while now, we're building some really powerful debugging capabilities there as just one thing to mention with remote debug right out to your Linux machine or VM

Does that mean VS will support C11 features?

Does the clang frontend for their backend not address that already?

The Linux workload is designed to work with GCC today, so whatever standard level your GCC compiler supports is good.

the debug mode is still starting up too slow, i dont know if it's possible to improve that but even if i disable copying sources it takes an additional ~5 seconds for it to work on the same machine (linux on a VM running in vmplayer with shared folders active)

That is the natural extension of Linux Subsystem on Windows.

PM for this at MS. We do work with WSL but do not rely on it. Currently we treat it as another remote Linux machine, just setup SSH in WSL and we'll work

Is this also integrated with the new Docker features that we saw in the live stream? I think being able to code in VS, build the project in ones favorite Linux distributions docker image and running or debugging it there sounds quite compelling.

If I develop in VS for a Linux target system how does VS know about the headers/libraries on the target?

Oh and a question that would surely interest some of my colleagues: Can it also be used to build and debug Linux kernel stuff, e.g. kernel modules?

Enable ssh in your dockerfile and you are good to go there, see this one as an example: https://hub.docker.com/r/ducatel/visual-studio-linux-build-b...

Regarding headers/libs you would need to manage that yourself, I normally scp them down locally and add to my Intellisense paths.

Regarding the kernel that isn't something I've played with much, I've been able to load the source but I have not tried any debug scenarios there.

I think there is really only one feature Microsoft cares deeply about in this, and that is "Easy Azure integration". All the big fish are going to work hard to collect rent on whatever SAAS they can.

Why twist yourself in knots to be the "next X" when you can be content supplying the "next X" with a platform for expansion.

Great to see some Resharper features making it in, have been waiting for MS to acquire Resharper or Jet brains :P; but why acquire when you can make your own Slack and Resharper :)

> have been waiting for MS to acquire Resharper or Jet brains :P;

Please don't. They make way too many awesome tools outside of Microsoft's area of interest, like CLion, Kotlin, RubyMine etc.

Kotlin is my fav!

I'm tempted, but when I tried 2015 RC shit broke like crazy when I upgraded to the actual release.

I was bitten like this with an RC of an earlier VS version (maybe 2012, I don't recall). I haven't touched a VS RC since, and doubt I ever will!

Does this also mean a new C/C++ runtime library is available (i.e. vcruntime150)?

Yes, though like before most of the crt is part of the windows universal crt

MSVC STL dev here. We're doing something different this time around. VS 2015 RTM and Update 1/2/3 were binary-compatible (as usual) while adding lots of features to the compiler and STL (unusual). VS 2017 RTM and its Updates will continue to be binary-compatible while adding features, meaning that our DLLs are still vcruntime140.dll, msvcp140.dll, etc. The versions are admittedly a mess, so here's the magic decoder ring:

VS 2015: IDE version 14, DLL version 140, toolset version 140, compiler version 19.0 (the C++ compiler is older than the Visual part of Visual C++). VS 2017: IDE version 15, DLL version 140 (same!), toolset version 141, compiler version 19.1

We still recommend that you build everything with VS 2017 consistently, as this will give you the most performance and correctness. However, you can mix in object files, static libraries, and DLLs compiled with previous versions all the way back to 2015 RTM, and things will continue to work (although you won't necessarily activate fixes in the newer version).

For more info, read the comments on https://blogs.msdn.microsoft.com/vcblog/2016/08/24/c1417-fea... where I mentioned WCFB02.

Thank you. I seem to have completely missed all the VC blog posts about the bincompat decision with regard to Visual Studio "15"/2017.

Glad to know that the VC100 to VC140 overhaul that I completed only very recently can still be considered fully up to date with the latest and greatest :).

Yeah, it makes migrating a codebase with third-party libraries built with older toolsets easier. Note that you'll need to build with VS 2017 if you want header-only improvements like the vector overhaul, and you'll need to update to 2017's VCRedist if you want DLL improvements (e.g. if you're still on 2015 RTM's msvcp DLL, you don't have the iostreams correctness/performance fix that shipped in 2015 Update 2; DLL improvements are uncommon but they do happen).

Project.json for .net core is gone, there's xproj file. How to change settings, like target framework, per-framework dependencies, build options, pre/post build steps, etc? I don't see any tooling support for that.

That went away a while ago, unfortunately... though I think yaml may have been better, the json-like structure was much easier than the xml mess for vs projects.

Hoping they added an "empty" project that is just files, closest were some of the web projects, but even then, node projects always felt like an alien afterthought... haven't seen how they are in vs2017, guessing they brought in the ntvs stuff into mainline.

From what I've read, Microsoft decided to reintroduce MSBuild as their unified build platform. This includes good ol' csproj and sln files, with a caveat that the actual contents of those files have been greatly simplified. It's still XML.

SLN files aren't really MSBuild (it can read them, but for any sort of build automation, you're going to be better off with a .proj file referencing all your actual projects).

project.json is still official way of configuring the projects. Dotnet cli uses that, msbuild is not there yet i think. Empty project is done with "donnet new", and it's really small and light ...

The information I've read claims that the new MSBuild system will be released along with what is now called Visual Studio 2017 and .NET Standard 2.0.

Recent versions of the dotnet cli work with both xproj and project.json for the time being, but have defaulted `dotnet new` to the xproj output. It also provides a `dotnet migrate` command to convert a project.json to an xproj.

xproj was the transitionary MSBuild scaffold, I meant csproj, things are returning to the csproj extension.

Some details of it all: https://blogs.msdn.microsoft.com/dotnet/2016/11/16/announcin...

The problem with the proj xml files isn't that they are XML but that they weren't meant for human editing.

So long as they fix that (no guids, include source files with just source/.cs instead of listing each file etc) then I don't mind XML. In fact I prefer hand editing XML over json if the amount of configuration is nontrivial.

From what I've seen in the presentation today they addressed these points. There are no more guids, and you can use wildcards for source files.

They seem to go back and forth on that every couple of months.

Nitty gritty details and examples here https://blogs.msdn.microsoft.com/dotnet/2016/11/16/announcin...

Anyone know if this will work with Unity 3D?

It seems so:

Game development with Unity The Unity engine integrates into one unparalleled platform to create 2D and 3D games and interactive content. Create once and publish to 21 platforms, including all mobile platforms, WebGL, Mac, PC and Linux desktop, web or consoles. Write code quickly and with precision using IntelliSense. Navigate through your scripts easily and use powerful refactoring capabilities. Identify issues quickly by debugging your Unity games in Visual Studio.

In a similar vein, Unreal Engine 4 added support for VS "15"/2017 in yesterdays 4.14 release.

https://www.unrealengine.com/blog/unreal-engine-4-14-release...

I've always been hesitant to install RC's on my machine.

Does anyone know how nicely the RC's generally play with other instances of VS / if they've improved that along with the improved install/uninstall process in 2017?

It's generally been part my job as a dev manager to be the first one to install Visual Studio RCs. I've never experienced any conflict other than Windows choosing the wrong version of Studio to open a project with when I double click a file.

In my experience, the RCs play nicely with other instances, but moving to the RTM is a complete nightmare.

Yes my 2013 and 2015RC ran very well together, but omfg when I tried to upgrade to 2015 RTM

I forgot about the upgrade to the RTM. Perhaps with the improved installer/uninstaller this may be a lesser issue. For now I'll stick to putting it on a VM, if I do.

Looks like the download page is getting hammered.

FWIW, the download buttons on the big white panels didn't work for me. If you scroll further down the page to the list of all downloads, that worked.

Piss-poor caching mechanism that can't spit out static frontpages with relative ease. Still getting 504's.

Here are direct links. Looks like they haven't updated the names in the URL's, but this downloads the 2017 RC.

https://aka.ms/vs/15/release/vs_Community.exe https://aka.ms/vs/15/release/vs_Enterprise.exe https://aka.ms/vs/15/release/vs_Professional.exe https://aka.ms/vs/15/release/vs_TestProfessional.exe

Thanks.

This is exciting, trying out now.. installer seems pretty smooth

Happy to hear! If you have any feedback or run into any issues, go to Help > Send Feedback in the IDE. Thanks! Cathy (Visual Studio IDE Team)

Looks like MS is making mostly small changes, focusing on improving the features they already have instead of introducing lots of new changes.

They're integrating xamarin into visual studio. That's pretty big no?

It is.

Is the new xamarin going to be any less buggy?

My experience with reporting a bug in Xamarin the other day was that it was fairly quickly reproduced and fixed. If you're hitting bugs I'd really recommend reporting them if you're not already.

I believe the install experience is getting a lot better as well.

At the Build conference they had a demo where they "forgot" to install VS before the presentation, and then installed it from an USB stick in about one minute.

I'm installing now, but not from USB...

Visual Studio 2017 installer experience is one of our biggest investments, we know this has been a pain for folks and we're committed to doing everything we can here.

Check out our detailed blog post on the topic:

Visual Studio “15”: Installing Just What You Need https://blogs.msdn.microsoft.com/visualstudio/2016/04/05/vis...

Thanks a bunch for this. I've always had huge problems with the installer.

I try to minimize this by installing it on an absolutely clean Windows installation. It's usually the first major thing I install after Windows Update patches and a few minor apps like 7zip and Chrome (used to use WinCdEmu back when I had VS Pro from Sparkfun instead of VS CE). I do this deliberately to try and minimize issues and I still have tons of issues with crashes during the install, and it is pretty much an overnight thing on many systems (or at least multiple hours). It's to the point where I will image the system so I can quickly blow down a clean image and give it another try.

I feel like part of this is the Windows team screwing you. OS upgrades are always tricky and the "system reset" thing does not actually work as fully as people expect that it does (eg it still keeps system files/drivers, config/registry, etc). My success rates were always higher with a 100% clean OS install, format everything and installing from a Media Creation Tool system image. My success rates have also been going up over time, and I'm sure both the VS team and the Windows team are coming at it from both sides, so props.

Keep it up with the DotNet environment too, the open-source direction is really important because it catalyzes the tooling and infrastructure that's been missing from the DotNet ecosystem. I mostly program in Java right now because of the end-to-end tooling and environment flexibility, but I really would prefer to work in C# and in the last 2 years you've made huge strides to making that possible.

I realize this is a totally different team, but right now my single biggest beef with MS products is the fact that major Windows updates usually reset all my settings. Things like ClassicShell need to be reinstalled each time, it forgets all my taskbar preferences, it forgets all my file associations, etc. The last one is particularly aggravating, especially when MS reps claim it's just because apps are setting associations by themselves when you are supposed to do it through the Windows interface. First off that's a terrible UI experience, but it nevertheless does reset anyway even if you do it through the Windows UI. People are going to hate updates a lot less if they don't insist on (metaphorically) playing with all my settings on my stereo. Please whisper that in someone's ear if you ever get the chance.

But overall MS products are really picking up steam after a prolonged era of poor quality. Windows 8.1 was fantastic, 10 is even faster. VS2012 was much better than 2007/2008 and 2015 CE has been great too.

Generally a good approach to take with something like VS.

In MSVC's STL we're making major changes, adding lots of features in pursuit of C++17 conformance. Among other things, we've added several new headers between VS 2015 Update 3 and VS 2017 RC (<string_view>, <optional>, <variant>, <any>), and we've totally overhauled std::vector's implementation for correctness and performance.

So, when will cl support two-phase name lookup?

Reply on news.ycombinator.com