VS2017 and .net frameworks
Once upon a time, each new Visual Studio brought a new .net framework. You couldn't use the new framework without the new Visual Studio.
- Visual Studio 2002 came with .net framework 1.0
- Visual Studio 2003 came with .net framework 1.1
- Visual Studio 2005 came with .net framework 2.0
- Visual Studio 2008 came with .net framework 3.5
- Visual Studio 2010 came with .net framework 4.0
- Visual Studio 2012 came with .net framework 4.5
- Visual Studio 2013 came with .net framework 4.5.1
- Visual Studio 2015 came with .net framework 4.6
(Update 1 was .net framework 4.6.1) - Visual Studio 2017 comes with .net... framework 4.6.1
Yes, even though 4.6.2 came out in mid-2016, the base 2017 is still 4.6.1. If you installed 4.6.2, it appears in the dropdowns, but if you haven't, you get 4.6.1. Exactly the same as VS2015.
However, you can write code in VS2017 that won't compile in VS2015, even though it targets the same .net framewok. The reason is that VS2017 comes with a new version of C#.
VS2017 and C# 7
C# (and the csc.exe compiler) isn't the same thing as the .net framework. You may have noticed this with C#6 in VS2015, when you could write null conditionals (x?.property), string interpolation ($"Hello {x}") and auto-property initializers (public string X {get;set;}=< 1) even if you targeted .net 3.5.
For C#7, the new features are pattern matching (switch based on types), not declaring out variables, returning tuples (without System.Tuple), local functions and others. They will work fine in VS2017, but VS2015 will choke on them.
Visual Studio build is just calling MsBuild (as you can see in the Output window). Let's look under the covers at what's happening.
VS2017 and MsBuild/Command Line building
Visual Studio used to use the msbuild and csc.exe in C:\windows\Microsoft.NET\Framework\v4.0.30319\ (or the previous .net framework locations)
With VS2015 and the new roslyn compiler, MsBuild and csc moved to Program Files/MsBuild, specifically C:\Program Files (x86)\MSBuild\14.0\bin\ (14.0 indicating Visual Studio 14, which is VS2015). Note the compiler isn't just .net 4.6, it compiles any project targeting 2.0, 3.5, 4, 4.5.* and 4.6.*
With VS2017, it's moved again. And it's in 2 places. Or more.
- Firstly there's a Program Files/Visual Studio, specifically (for Community) C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\ (csc is under Roslyn\)
This is the only version used by Visual Studio, and supports all project types. - There's another copy (NOT used by Visual Studio, but used by the "dotnet build" command line) at C:\Program Files\dotnet\sdk\. For the VS2017 RC4 version, the matching sdk is at C:\Program Files\dotnet\sdk\1.0.0-rc4-004771\.
If you update the dotnet sdk, C:\Program Files\dotnet\sdk\ is updated but Visual Studio won't be. - You can install a local version through nuget using "install-package Microsoft.NET.Sdk"
Confused yet?
Most projects I build have a "build.cmd" file which runs an msbuild script called "build.xml" (or .csproj). It's an easy way to generate a clean "publish" folder (see here). The .cmd file requires the path to msbuild, which now becomes difficult.
The new "dotnet" command (and the sdk package) works on some classic full framework projects with traditional csproj files - a class library and a console (even if built in VS2015). It doesn't work against a "classic" mvc 5 web application, even one built in VS2017. The msbuild that "dotnet build" runs is a dotnet Core version of msbuild, not the full Visual Studio one. It works against a simple "non-core" csproj, but it's really a different, more limited, pipeline to the full msbuild. Note that in addition to "dotnet build", RC4+ has dotnet msbuild to access msbuild directly.
VS2017 and .net Core
The .net Core tooling/build system (SDK) has changed, but VS2017 doesn't bring a new Core version (which makes sense - it is updated through muget). NetStandard 2.0 is coming, but not for a while- it seems to have been delayed until 2017 Q3, perhaps a 6 month delay.
- If you open VS2015 Core projects in VS2017, you get an automatic upgrade from project.json to csproj.
- You can't open VS2017 csproj core projects in VS2015. It only understands the now obsolete project.json
Between VS2010 and VS2015, csproj was forward and backward compatible, so life in a typical company with mixed versions of Visual Studio was remarkably uneventful. With VS2017, at least for Core, all developers must upgrade at the same time. It could be awkward for larger open source projects, although VS2017 Community makes upgrading free. Most companies take their time rolling out new Visual Studio versions too.
Upgrade
Since 2010, new Visual Studio versions have come with new .net framework versions, but we've been backwards compatible. Back compatibility started to break with VS2015 and C#6 and breaks again with VS2017 and C#7. Worse, Core is a big breaking change, and teams with a Core project must upgrade at the same time.