[Bug]: Debug Error on Manifest creation or deletion in build process

[bryfa]

Detailed steps on how to reproduce the bug

Building plugin on Windows 11 and JUCE 7.0.8 gives build error on creating the manifest.

Just create or open a project and build the plugin. I got a "Windows Runtime C++ Runtime Lib" dialog with the message:
Debug Error!
Pogram: ... \Debug\VST3 Manifest Helper\juce_vst3_helper.exe
abort() has been called presse "Abort", "Retry" or "Ignore"

Everything seems to build correctly, but there is a problem with the manifest creation, deletion or whatever.
Its on of the last steps in de build process

What is the expected behaviour?

Should build without this issue as it did on the previous version 7.0.7

Operating systems

Windows

What versions of the operating systems?

Windows 11 Pro Version 10.0.22621 Build 22621

Architectures

x86_64

Stacktrace

No response

Plug-in formats (if applicable)

No response

Plug-in host applications (DAWs) (if applicable)

none

Testing on the develop branch

I have not tested against the develop branch

Code of Conduct

• I agree to follow the Code of Conduct

[tpoole]

Can you please try the develop branch? I think this issue has been addressed.

[bryfa]

Tried with the dev branch and did not get the error in the first build, but did got the error in the second build:

Short build log:
Build started...
1>------ Build started: Project: CCVEQ_VST3, Configuration: Debug x64 ------
1>CCVEQ_VST3.vcxproj -> ...\Builds\VisualStudio2022\x64\Debug\VST3\CCVEQ.dll
1> 1 file(s) copied.
1>Deleted file - ...\Builds\VisualStudio2022\x64\Debug\VST3\CCVEQ.vst3\Contents\Resources\moduleinfo.json

then I got the error..

[aminya]

I can reproduce a similar error building with CMake/Ninja and Clang using Juce 7.0.10. It works on other platforms but not on Windows.

juce_vst3_helper fails with no errors:

 H:\GitHub\test\build\packages\test\Release\juce_vst3_helper.exe -create -version 0.0.1 -path H:/GitHub/test/build/packages/test/test_artefacts/Release/VST3/test.vst3 -output H:/GitHub/test/build/packages/test/test_artefacts/Release/VST3/test.vst3/Contents/Resources/moduleinfo.json""

I tried various other combinations of flags like removing --output, but all of them failed.

Can you add more logging to get more information?

I noticed that Juce's VST3 SDK has diverged from the upstream a bit. Those changes could be the reason why this fails.
https://github.com/steinbergmedia/vst3sdk
vs
https://github.com/juce-framework/JUCE/tree/master/modules/juce_audio_processors/format_types/VST3_SDK

Especially the changes in:
https://github.com/juce-framework/JUCE/blob/master/modules/juce_audio_processors/format_types/VST3_SDK/public.sdk/samples/vst-utilities/moduleinfotool/source/main.cpp

[aminya]

I dived into the issue, and I could get more information for the error. It turns out that some error was being ignored by the VST3 SDK. I have submitted a pull request for that:

#1371
steinbergmedia/vst3_public_sdk#68

My issue is that the VST3 SDK helper fails to load the .vst3 folder as a package. It says that the actual .vst3 file doesn't exist, although it does.

LoadLibray failed for path ./build/packages/test/test_artefacts/Release/VST3/test.vst3\Contents\x86_64-win\test.vst3. The specified module could not be found.

The main issue is that my .vst3 has a .dll dependency that was not on the PATH so Windows fails to load it. As soon as I added my .dll to PATH, it fixed the issue

[QuentinFAIDIDE]

Any tips on troubleshooting which dll is missing ?

Edit: I manage to solve my issue, using LucasG's Dependency on the vst3 file did not show any missing dependency, but it turned out that LoadLibraryW was expecting the dlls that were shipped in the vst3 file folder to be in the same folder as juce_vst3_helper.exe instead. To be more precise, the ./VST3/test.vst3\Contents\x86_64-win\ folder was not in the search paths used by this call to LoadLibraryW.

For future readers, JUCE developers on the JUCE forum discourage using dynamic libraries as DLLs, as there can be version compatibility issues with other DLLs loaded on the system. It is advised to instead use static libraries. Using static libraries will also solve this issue.