>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.
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.
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.
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.
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.
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.
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.
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.
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".
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).
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.
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.
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.
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)
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.
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.
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.
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
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)
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?
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 :)
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).
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.
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 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 ...
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.
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.
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?
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.
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 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.
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.
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.
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.
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.
"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.