I didn’t know it was wrong. What is the correct extension?
That’s on macOS, not on Windows. Projucer uses
.aaxplugin on macOS:
Now I remember what is happening! The
MyPlugin.aaxdll file is copied as
MyPlugin.aaxplugin/Contents/x64/MyPlugin.aaxplugin in a post-build step:
This means that the
.aaxdll extension isn’t relevant, it could be
It’s relevant when you use other tools which have scripts which expect the correct extension.
I can create a post build batch file to rename the protected version back to aaxplugin. but I still believe this is a bug
If the binary is named
MyPlugin.aaxplugin, then it is not possible to make a folder named
MyPlugin.aaxplugin next to it, due to the name conflict.
I get the chicken and eggs scenario… but I think the target name should be consistent… so the folder should probably be somewhere else to avoid the issue… Bottom line for me it’s not a huge deal to run a post build script to copy the final versions and rename them to .aaxplugin – this just seems wrong when looking at the settings.
I think the original mistake was made by AVID when they chose to use (on Windows) the “.aaxplugin” extension both for the folder AND for the binary that it contains.
On macOS, the bundle (equivalent to the Windows folder) has the “.aaxplugin” extension but the binary inside it has no extension (like all other binaries inside bundles).
With respect to this, leaving the native “.dll” extension for the binary on Windows inside the “.aaxplugin” folder would have made much more sense, and I think ProJucer uses “aaxdll” both for avoiding name clashes and as a reminder that the resulting file by itself is not a valid AAX plug-in, but just the binary that goes into it.