Virtual Studio Technology (VST) for .NET. Plugins and Host applications.
Hopefully some helpful tips when things don’t work right away.
As a workaround to another problem with using NuGet packages in a mixed assembly project, the dependencies for the interop library are hard-coded in the vstnet cli.
Because of that, the final step after a successful build may display warnings
that certain dependencies were not found at the NuGet package cache location:
Currently the simplest way around this is to add the missing NuGet dependencies to your project - even if you don’t use them. Make sure you match the exact version of the package.
Depending on the host, a plugin may not load into the DAW. First things you should try:
Typically a DAW scans for plugins on either specific file locations or using a configurable list of paths.
Make sure that the plugin matches the processor architecture of the host.
That means if the host is 64-bits, your plugin needs to be build for
x64 and the same goes for 32-bits (
x86) of course.
Most application these days are 64 bits but not all!
This almost always means that you are mixing 64-bit (x64) code with 32-bit (x86) code. It could be that not all your dependencies are for the same system architecture (x86/x64) or that you are trying to load 32-bit plugins into a 64-bit host application (or visa versa).
In order to eliminate problem areas, you should check if your plugin is correct and has all the required files in its deploy folder.
During development of VST.NET itself the vsthost is used as a test host. If your plugin does not load in this host you know that you are missing files. You just need to test if the plugin loads (File->New Plugin…).
Ijwhost.dllinto host .exe’s folder
This problem should have been fixed in RC3 - but I leave it here if anybody may need it. Please report an issue if you do.
For some hosts the loading of .NET core does not work at all. It is unclear what the problem is,
but copying over the
Ijwhost.dll file into the same folder the host’s .exe is located usually solves the issue. The Ijwhost.dll can be found in de ‘deploy’ folder.
If all else fails, you may have to attach the debugger, explained here.
Back to Index