The most recent JUCE-compatible version of the VST3 SDK that supports VS2013 is 3.6.7, which is now a couple of versions behind the latest (3.6.9). So, unless you’ve kept an old version of the SDK handy, compiling with VS2013 is going to be difficult.
Is anyone unable to use a more modern version of Visual Studio? It would be nice to raise our minimum to VS2015 and have access to additional, more modern, C++ features within JUCE.
Would this mean developing on VS2015 with the v140 toolset as the minimum? Would we still be able to develop with the v120 toolset on VS2015 with this considered change?
I have an older project that I compile on windows with v120 for Win7 compatibility. I’ve just stuck to that toolset over the years because I know it works. Truthfully, I haven’t tested it building with v140 instead, and it might work just the same.
I wonder what the motivation is to use the v120 toolset vs. just using the v140 toolset. If you’re after Windows XP support, then there is a perfectly serviceable v140_xp toolset available. You can even use Visual Studio 2017 with the v140_xp toolset.
Even Visual Studio 2017 has no problem with Windows 7 compatibility. I run the latest VS2017 on Windows 7 and build with toolset v141. (And obviously can run the resulting binaries… )
I’m still on VS2013 because I experienced that XP support is broken on later versions of VS: It compiled fine with v1x0_xp, but binaries and dlls didn’t work when testing under XP. Has someone here successfully created XP compatible plugins with a version > 2013 of VS?
Otherwise it’s probably time to finally drop XP support.
It is possible to build for xp and run binaries and .dlls with VS2017. You linked to my post, but there are other threads where I found the solution. You need to use a v1x0_xp toolset and for dlls to load correctly you need to set an extra compiler flag:
It would cause me major issues I think, as I can’t build against the (very old) hardware interface library I’m using in later versions of Visual Studio. I’ll have another go to see if I can get it working, but I suspect I’ll be stumped without VS2013 support
I’ll also look into whether the /Zc:threadSafeInit- flag makes any difference…
Supporting the v120 toolset with VS2015 is equivalent to supporting VS2013 itself: you can’t use it with the most recent VST SDK versions and you can’t use more modern C++ features. So I don’t get your answer…
Yes, in hindsight my comment wasn’t particularly useful… you can use the v120 toolset, but it’s not going to be any help with things like constexpr or more recent VST SDKs.
Given the relative lack of outcry at my suggestion of dropping VS2013 support it seems likely there are only a few people who still require it. I’ll keep commenting on this thread to give it visibility over the next few weeks and if there’s not a lot more resistance then we’ll move forward with this.
I’m happy to put more time into moving to a later version of VS, as I’d prefer to converge on 2017 if possible. Just nervous, as last time I tried it didn’t work out. I’ll post back here with my experiences after I’m back from holiday in a week.
The current AAX SDK (2.3.1) readme says it’s not fully compatible with VS2017 and that it has not been tested by Avid, so this kind of put me off jumping over to 2017. It would be good to know if this is unnecessary caution on my behalf and it’s basically fine.
I’m moving all my 2013 projects over to 2015 as I’m getting tired of the lack of support for some of the newer C++ features. Losing 2013 support makes me a bit nervous in case I need to revert though.
I use VS 2017 to compile the AAX SDK 2.3.1 and so far there haven’t been any problems. I think it’s totally fine. For building you need to disable the “treat warnings as errors” flag in VS. 2017 is a lot more strict than older versions.