How many people are using Visual Studio 2013?

Just curious: what are you trying to archive by using the v120 toolset instead of the v140?

It’s possible to use the v120 toolset with VS2015, it’s just not installed by default and we’d need to add it to the dropdown menu in the Projucer.

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… :wink: )


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.

Related discussion: Building with MSVC 2015 for Windows XP

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:


For more explanations see this message:

1 Like

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 :frowning:

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…

P.S. I’m not using VS2013 to compile VST plugins. I use VS2017 for that.

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.

@samuel @w_ellis

Can you provide a few more details? Perhaps we can work around your issues.

1 Like

Even though I didn’t find time yet to test what pflugshaupt has suggested, I’m fine with dropping VS2013 support in JUCE.

1 Like

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.

Just bumping this topic again to keep it visible.

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.

1 Like

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.

1 Like

VS2017 here for quite some time. And using all the latest updates and SDKs. No issues.

And, I always compile with “Treat Warnings as errors” turned on. No problem.

1 Like

turning off the “treat warnings as errors” is just to get the AAX sdk to compile without dealing with all those warnings.

Yep, your absolutely right! The AAX SDK must be compiled with “warnings as errors” turned off, otherwise it is a mess!