[Interest] Support for Visual Studio 2017

Tom Isaacson Tom.Isaacson at navico.com
Sun Feb 26 19:45:47 CET 2017


Final release is on March 7th.

We still need the Qt Visual Studio Plug-In. There's a comment from Karsten Heimrich on the last release page:
http://blog.qt.io/blog/2016/11/11/qt-visual-studio-tools-2-0-released/
"I did an initial commit that supports VS 2017 RC, you can find it here: https://codereview.qt-project.org/#/c/177499 Once we did some more testing, I will upload an RC at download.qt.io."
Does anyone know if this happened?

Tom Isaacson

-----Original Message-----
From: Interest [mailto:interest-bounces+tom.isaacson=navico.com at qt-project.org] On Behalf Of Constantin Makshin
Sent: Sunday, 26 February 2017 12:51
To: Qt Interest <interest at qt-project.org>
Subject: Re: [Interest] Support for Visual Studio 2017

Well, if that's true (we still have to wait for the final release of
VS2017) then, as Harri said, upgrade from VS2015 will be much easier for everyone. :)

On 02/24/2017 08:51 PM, Tom Isaacson wrote:
> VS2017 is ABI-compatible with VS2015:
> http://stackoverflow.com/questions/40854917/is-visual-c-2017-binary-co
> mpatible-with-vc-2015
> 
> There's a comment here that suggests VS2017 uses the same C++ standard library implementation (search for "msvcp140.dll"):
> https://news.ycombinator.com/item?id=12967901
> "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."
> 
> Tom Isaacson
> 
> 
> -----Original Message-----
> From: Interest 
> [mailto:interest-bounces+tom.isaacson=navico.com at qt-project.org] On 
> Behalf Of Constantin Makshin
> Sent: Saturday, 25 February 2017 00:22
> To: Qt Interest <interest at qt-project.org>
> Subject: Re: [Interest] Support for Visual Studio 2017
> 
> Still looks somewhat risky to me. Unless VS2017 uses C++ standard library implementation from VS2015's "msvcp140.dll", of course.
> 
> On 02/24/2017 12:44 PM, Tom Isaacson wrote:
>> I had the prebuilt VS2015 libraries downloaded and installed and I was able to rebuild and run our app in VS2017. I didn't have to rebuild Qt myself.
>>
>>
>> Tom Isaacson
>>
>> -----Original Message-----
>> From: Interest
>> [mailto:interest-bounces+tom.isaacson=navico.com at qt-project.org] On 
>> Behalf Of Harri Porten
>> Sent: Friday, 24 February 2017 20:30
>> To: interest at qt-project.org
>> Subject: Re: [Interest] Support for Visual Studio 2017
>>
>> On Thu, 23 Feb 2017, Tom Isaacson wrote:
>>
>>> It worked for me; I was able to run our VS2015 app in VS2017 with no problems.
>>
>> I think Thiago meant something different: what if you are compiling your application with VS 2017 against a set of Qt libraries build with VS 2015? 
>> If that works flawlessly a big upgrade pain of the past would be gone.
>>
>> Harri.



More information about the Interest mailing list