Post build error [MSB3073] in Visual Studio

Audio Plugins
1

Hello everyone, I’m trying to build a VST3 plugin which includes the ZeroMQ library. I’m able to build it when I’m including the header

#include <zmq.hpp>

But as soon I decomment the parts where I declare zmq objects:

zmq::context_t context{ 1 };
zmq::socket_t requester{ context, zmq::socket_type::req };

I get the following error:

MSB3073	The command "setlocal
"C:\Program Files\CMake\bin\cmake.exe" -E echo "removing moduleinfo.json"
if %errorlevel% neq 0 goto :cmEnd
"C:\Program Files\CMake\bin\cmake.exe" -E remove -f C:/Users/rizzo/Desktop/TESI/MaestralDAW/build/Maestral_artefacts/Debug/VST3/MaestralDAW.vst3/Contents/moduleinfo.json C:/Users/rizzo/Desktop/TESI/MaestralDAW/build/Maestral_artefacts/Debug/VST3/MaestralDAW.vst3/Contents/Resources/moduleinfo.json
if %errorlevel% neq 0 goto :cmEnd
:cmEnd
endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
:cmErrorLevel
exit /b %1
:cmDone
if %errorlevel% neq 0 goto :VCEnd
setlocal
"C:\Program Files\CMake\bin\cmake.exe" -E make_directory C:/Users/rizzo/Desktop/TESI/MaestralDAW/build/Maestral_artefacts/Debug/VST3/MaestralDAW.vst3/Contents/Resources
if %errorlevel% neq 0 goto :cmEnd
Debug\juce_vst3_helper.exe -create -version 0.0.1 -path C:/Users/rizzo/Desktop/TESI/MaestralDAW/build/Maestral_artefacts/Debug/VST3/MaestralDAW.vst3 -output C:/Users/rizzo/Desktop/TESI/MaestralDAW/build/Maestral_artefacts/Debug/VST3/MaestralDAW.vst3/Contents/Resources/moduleinfo.json
if %errorlevel% neq 0 goto :cmEnd
:cmEnd
endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
:cmErrorLevel
exit /b %1
:cmDone
if %errorlevel% neq 0 goto :VCEnd
:VCEnd" exited with code 1.	Maestral_VST3	C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets	166

I really can’t see how these two things are related (or maybe they aren’t). The plugin itself actually builds, but I can’t run it in any DAW. I tried to run the plugin in AudioPluginHost as suggested here (Suddenly can't build vst3 in Windows...|Error|MSB3073|The command copy /Y) and I’m failing the assertion showed in the attached image.

error
error1886×888 101 KB

Suddenly can't build vst3 in Windows...|Error|MSB3073|The command copy /Y
3

Ok I’m going to explain better my setting:
I’m using ZeroMQ to communicate between my plugin and another thread where I run some Python code which receives MIDI messages, elaborates them through a deep learning model, and sends back new MIDI messages to my plugin.
When I run all of this in standalone mode it works: the new thread is created and the communication works fine. When I try to build the VST3 plugin it fails,but the reason for the failure is beyond my understanding.

4

Hi! Any clues? Same here, standalone builds but VST3 fails with the same error.

I use some .dlls which I already copied to the folder

5

I went for using Windows pipes :cry: gonna move to another framework when I’ll refactor the project

6

@reuk hi! any ideas? I’ve been digging the forum and saw lots of answers from you on similar topics

7

The problem is likely that the VST3 is crashing or failing to load for some reason at the point where the VST3’s manifest file is generated.

I assume you’re using CMake. You could try adding the VST3_AUTO_MANIFEST FALSE arguments to your juce_add_plugin call. This will disable the manifest generation step, allowing the build to complete so that you can debug the resulting build as normal. Once you’ve determined the cause of the problem, I recommend re-enabling the auto manifest.

8

Thanks @reuk for your answer!

I was able to avoid the problem by setting that argument to FALSE.

Now I’m encountering that it only runs if the executable has the .dlls on the same folder (I copy them to the vst3 inner folder, but only works if I copy them to the AudioPluginHost.exe folder).

So I assume that the manifest is not created because the process open doesnt have the .dlls.

Is there a way to make it search the .dlls in the vst3 folder and not the daw/manifest creator process folder?

Thanks in advance, hating dlls and Windows so far haha

9

Not as far as I know. Distributing plugins that link DLLs is tricky too, and I wouldn’t recommend it. As you’ve already discovered, the DLLs need to be placed next to the host app, which will make it difficult to support arbitrary hosts, unless your users are prepared to do this DLL juggling themselves.

Some better alternatives:

  • Instead of using DLLs, use static libraries or build your dependencies directly into your plugin. This approach is the most straightforward.
  • Failing that, install your DLL to a known location, and then load it dynamically, e.g. using juce::DynamicLibrary.
10

Thanks again. Lost a day but learned something :slight_smile:

Some of my DLLs are only provided in dynamic version, not static.

What about the juce::DynamicLibrary ? How do I use classes from the libraries? Do I maitain the includes? Any example? Just saw it rapidly and seemed to me just to be a function finder inside the library