Projucer 7.0.7 MSVC Exporter bug with VST3 post-build script

The VST3 build fails on Windows 10, indicating an exit code 3 from the post-build script that runs the VST3 helper.

Culprit is the Projucer code that assembles this post-build script. It doesn’t seem to be able to deal with custom Binary Location and/or custom Intermediates Path. In jucer_ProjectExport_MSVC.cpp in getExtraPostBuildSteps()

const auto writer = writerTarget->getConfigTargetPath (config) ...

delivers a path that points to inside the plugin’s config target path. The VST3 helper however has its own path next to the plugin at the same level. At east that’s the case when custom binary/intermediates paths are in effect.

As a test I hard-wired this path in Projucer and the build worked fine. Someone with better knowledge of the Projucer code should look into this. Should be a relatively simple fix.

At the moment I’m not able to reproduce this issue.

  • Is the issue definitely present on develop?
  • Which exporter are you using (2017, 2019, 2022)?
  • What are some examples of problematic paths? I’ve tried relative and absolute paths for both the intermediate and output location, and both seem to work as expected.

If possible, please send me a copy of the problematic jucer file via direct message.

I checked develop branch and the source for the exporter has not changed since 7.0.7. The problematic configuration is with VS 2019 where Binaries and Intermediates paths are both set to:


You should see the error when you use a similar directory that ends with $(ProjectName)$(Platform)$(Configuration)

Did this setup work at any point before JUCE 7.0.7?

If I use the paths you provided, then the build does fail for me - on 7.0.7 and on 7.0.5. The cause is that the $(ProjectName) macro evaluates to “MyProject_SharedCode” when building the shared target, but “MyProject_VST3” when building the VST3. When the LibraryPath for the VST3 target includes $(ProjectName), VS searches for the shared code library in the VST3 build dir rather than the SharedCode build dir.

Yes, this worked for many years until (and including) 7.0.5. In fact I had to revert to 7.0.5 to be able to build again.

The cause is that the $(ProjectName) macro evaluates to “MyProject_SharedCode” when building the shared target, but “MyProject_VST3” when building the VST3.

Exactly. I suspect there is some method that doesn’t take custom paths into account where it should. In my setup both $(ProjectName) folders happen to be in the same parent folder.

I can see that projects that use the $(ProjectName) macro might fail in some situations. However, I don’t understand why this issue would only affect the new post-build script in your case, when it completely breaks linking plugin targets for me.

In the generated vcxproj for the VST3 target, what does the LibraryPath node look like? Does it definitely include $(ProjectName) somewhere? If so, have you made any changes to the Projucer project that would allow the shared code library to be found at this path?

The generated VST3 project uses these:

<OutDir Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">T:\BUILDS\CURRENT\Products\$(ProjectName)\$(Platform)\$(Configuration)\VST3\</OutDir>
<IntDir Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">T:\BUILDS\CURRENT\Products\$(ProjectName)\$(Platform)\$(Configuration)\VST3\</IntDir>
<LibraryPath Condition="'$(Configuration)|$(Platform)'=='Debug |x64'">$(LibraryPath);T:\BUILDS\CURRENT\Products\MyPlugin_SharedCode\$(Platform)\$(Configuration)\Shared Code;T:\BUILDS\CURRENT\Products\$(ProjectName)\$(Platform)\$(Configuration)\Shared Code</LibraryPath>

MyPlugin is the plug-in name.

Projucer added both library paths, which explains why it is found.
This output has not changed since 7.0.5.

Hoppla. Ok, in the .jucer file I’ve added this in Extra Library Search Path:

T:\BUILDS\CURRENT\Products\MyPlugin_SharedCode\$(Platform)\$(Configuration)\Shared Code

This explains why it builds and links.

But it does not explain why 7.0.7 won’t create a working post-build script.

1 Like