Ok… now I’m a bit confused about how it would have worked without those in older versions of VS.
There’s actually no need to modify the project - I normally add the libs using #pragmas, so it should be easy enough just to add these to the list of other PT libs, in juce_RTAS_Wrapper.cpp, line 110:
FYI: just tested the plugin and it works fine in PT9. It’s a basic test, but… This does mean that it’s definitely possible to build the PT8 library and RTAS plugins in vs2010 (I saw that you recommended using vs2005 a few years back).
That’s good news because it means we can build VST32+vst64+rtas32 in one environment.
For AAX on 'doze seems a bit early, right?
It’s getting weirder by the second… I tried that fix and sometimes I get things to work, sometimes I don’t. It’s VERY weird.
I’m investigating some more.
With the pragmas I never got it to build, but with the additional includes I did.
I did see that there was this rather interesting thing you wrote here:
#if JUCE_DEBUGxxx // (the debug lib in the 8.0 SDK fails to link, so we'll stick to the release one...)
#define PT_LIB_PATH JucePlugin_WinBag_path "\\Debug\\lib\\"
#else
#define PT_LIB_PATH JucePlugin_WinBag_path "\\Release\\lib\\"
#endif
Notice the “xxx”! In vs2010 this could lead to trouble as you are using release libs with a debug build…
Never mind Jules, don;t add that change, we’re going back to 2008 for RTAS. I tried just about everything in 2010 and sometimes (seemingly random!) it works, but doing another clean build it fails. That’s pretty scary, so no go.
One of the problems is that PluginLib defines _HAS_ITERATOR_DEBUGGING=0; even in Debug mode which makes vs2010 throw up lot’s of errors about iterator debugging. Removing the define in PluginLibrary skips those but then there are sudenly unresolved externals in RTASClientLib.lib. It’s all a bit of a mystery.
I’m afraid that the RTAS libs have always been very rather precarious in terms of the exact version of VS that they work with. Fingers crossed that the AAX SDK will be less fussy!