(No longer a) Breaking Change: VS post-build copy for plugins


#1

Just a heads up that this change to the Projucer on the develop branch now adds a post-build step to Visual Studio plugin targets that copies the plugin binary to a specified folder, or the default folder for its type if one is not specified. You can set the desired folder for each plugin type in the build configuration here:

If this field is left empty the default folders are as follows:

VST2 - Program Files\Steinberg\Vstplugins
VST3 - Common Files\VST3
RTAS - Common Files\Digidesign\DAE\Plug-Ins
AAX - Common Files\Avid\Audio\Plug-Ins

This is in line with the Xcode exporter and should hopefully make things a lot easier as each plugin format will be copied to its appropriate folder by default. However, it may cause some issues if you already have a post-build script set up to do this or if the default folders do not exist/you do not have write permissions to these folders. For example, we have had to modify our Windows build server to have the expected folders and have administrator rights to write to these folders otherwise the build would fail on the copy step when building the demo plugin.

Please post any bugs or issues with this change in this thread.

EDIT: Following this post below, this is no longer a breaking change. Carry on…


Windows Post-Build Script in the new system
#2

Awesome, thank you !


#3

Hi, can we set global defaults for these directories?


#4

I made a comment on the commit before seeing that you wanted feedback in this thread: https://github.com/WeAreROLI/JUCE/commit/d346d6ef50a132cde4e8a3bc8d4ef2d3e23761ee#commitcomment-25086030.


#5

Not currently, but that’s a good idea!


#6

That wasn’t intentional, there will be a fix for this on develop shortly.

EDIT: Fixed here


#7

Can i disable the automatic copy?


#8

No, it will always perform the copy step like the Xcode exporter. Would you want to disable it?


#9

Well yes, why shouldn’t i ask?
The major problem here i see, unlike on macOS, the default folders have adminstrator rights, which is security relevant. On macOS the user-space folders are used.
If i lower the rights on the specifc folder, any user-process can install software into that folder, which will be executed when i start any host software which uses plugins.
So basically any juce-developer will end up, change the rights on these folders.


#10

Yep that’s a good point. I think by default the copy step should be disabled in the VS exporter and enabled in the Xcode exporter, with an option to change this in both. I’ll add this to develop.


#11

is that still a “breaking change” with those default options?


#12

Nope. I’ve amended the post and I’ll remove it from the breaking change log on the develop branch. Thanks for reminding me!


#13

Now we’ve got separate output directories, can we lose the “App” that’s appended to the binary location field? thx


#14

Oh great, thanks so much!


#15

May I ask for one last small change here? It would be great if the /H flag could be added for AAX targets, otherwise the hidden PluginIcon.ico and desktop.ini are lost in the copy.

Thanks!


#16

And also /K to keep those files attributes in the copy. Again, thanks!


#17

I’ve added these extra flags, the change will be on develop shortly.


#18

@ed95 would be nicer IMHO to have VST2 get the one from the registry before falling back to the naive Steinberg\Vstplugins.

BOOL readVSTPluginsPath(VSTFolders* vstState, BOOL is64bit = FALSE)
{
   HKEY hKey = 0;
   WCHAR* buf = is64bit ? vstState->vstFolder_x64 : vstState->vstFolder_x32;
   DWORD dwBufSize = sizeof(WCHAR[MAX_PATH]);
   DWORD dwType = REG_SZ;
   LONG res = 1;

  BOOL hasVSTFolder;

  res = RegOpenKeyEx(

  HKEY_LOCAL_MACHINE,

  L"SOFTWARE\\VST", 0, is64bit ? KEY_READ | KEY_WOW64_64KEY: KEY_READ, &hKey);
  hasVSTFolder = (res == ERROR_SUCCESS);
  res = RegQueryValueEx(hKey, L"VSTPluginsPath", 0, &dwType, (LPBYTE)buf, &dwBufSize);
  hasVSTFolder = (res == ERROR_SUCCESS);

  if (is64bit)
      vstState->has64VST = hasVSTFolder;
  else
      vstState->has32VST = hasVSTFolder;

  RegCloseKey(hKey);

  return (res == ERROR_SUCCESS);
 }

(for example on my last install I’ve installed SONAR before others and it’s now being looked by all hosts under C:\Program Files\Cakewalk\Vstplugin :frowning: )


#19

That would only work if you were saving the .jucer project on Windows. The current method of using the fallback folder recommended by Steinberg here means that at least the folder will be consistent regardless of what platform you save the project on. However it’s just a default folder that should work for most users if they don’t set it themselves - can you not just modify the path to point to the folder specific for your machine?


#20

I assume this intention behind this commit is to simplify debugging.

You’re right, it can be easy to set it once you know your path.
But, It took me few minutes to understand Cakewalk got control on my registry VSTFolder. but it’s more fail-safe not to assume this is the folder just as the “default” Windows installation is usually C:\ .

In the link from Steinberg there’s:

This path can also vary due to customized installations and configurations but it is recommended to leave it as it is. Most 3rd party applications predefine the correct path on installation. Cubase and Nuendo can access their own plug-in folder but they can also utilize these shared folders if this has been configured correctly in the menu “Devices”, sub-category “Plug-in information”.

So just as each host could make your plug-in behave differently, many hosts read the value from the registry.

It might be nice that, if you leave it empty, that you’d get the default registry value under Windows.
(just as if you leave your Paths empty within the Projucer they’d figure them out from the default onces in the Projucer preferences).