This project has moved and is read-only. For the latest updates, please go here.

Can I use VST.NET with .Net 4.0

Topics: Deployment
Oct 26, 2011 at 4:38 AM

Is it possible to get a VST.NET application running with .NET 4.0? I just tried upgrading to 4.0 but now when I try to load up my VST in a host I get an error message that says: "this assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded".


Any idea what's going on here?



Oct 26, 2011 at 6:36 AM

Sounds like a standard manifest issue, here is how I modified 'app.config' to support 2.0 framework in 4.0 app:

<?xml version="1.0"?>
<startup useLegacyV2RuntimeActivationPolicy="true"><supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/></startup>
           <legacyCorruptedStateExceptionsPolicy enabled="true"/>

Oct 26, 2011 at 8:01 AM
Edited Nov 21, 2011 at 3:10 PM

I think that the version of the runtime that is loaded is determined by the Jacobi.Vst.Interop assembly that you renamed to your plugin name (MyPlugin.dll). That assembly is the first that gets loaded and therefor triggers the loading of the .NET 2.0 CLR - because no <runtime> directives were found in the .exe.config. Then the Bootstrapper loads in the Jacobi.Vst.Core assembly (still 2.0 so OK). and then the ManagedPluginFactory tries to load in your managed plugin assembly. But that is a .NET 4.0 assembly and the 2.0 CLR therefor throws the exception for it has no clue how to run a newer version assembly.

So, I think Yury is right to request in the exe.config the 4.0 CLR to be loaded with legacy settings enabled. 

The downside of this is that you have to deploy a [host].exe.config. I will look into providing the VST.NET binaries for the different platform CLR versions so that loading of the Jacobi.Vst.Interop trigger loading of the correct CLR version.

More info here:

Oct 27, 2011 at 2:08 AM

Yeah this is exactly the problem : loading a 4.0 assembly from a 2.0  runtime while there is no explicit <runtime> directives in the .exe.config.

If you're building a host instead of a plugin, I'd recommend adding the legacyCorruptedStateExceptionsPolicy flag to your assembly even if it's not clean. This is useful when loading a faulty plugin that throws an access violation exception, without the flag the application would crash instead of catching the exception.

Oct 27, 2011 at 2:43 AM

Thanks for the help guys! I've got things temporarily working with the config file from Yurk and I'll keep checking back to see if Mark has released the binaries for 4.0. Worst comes to worst I can always just switch back to .Net 3.5 as there isn't much that I'm using that is new in 4.0. I just got VS2010 so I figured I might as well try out 4.0.

Oct 27, 2011 at 3:32 AM

I would be nice to be able to use Mono instead of .NET so people can use VST.NET plugins on a Mac. I just tried compiling with Mono 2.8 in VS210 and its giving me the following warning:

The primary reference "Jacobi.Vst.Interop, Version=, Culture=neutral, PublicKeyToken=fa678e13c1efc859, processorArchitecture=x86" could not be resolved because it has an indirect dependency on the framework assembly "Microsoft.VisualC, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" which could not be resolved in the currently targeted framework. ".NETFramework,Version=v4.0,Profile=Mono". To resolve this problem, either remove the reference "Jacobi.Vst.Interop, Version=, Culture=neutral, PublicKeyToken=fa678e13c1efc859, processorArchitecture=x86" or retarget your application to a framework version which contains "Microsoft.VisualC, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".


Don't suppose there are any work-arounds for this?



Oct 27, 2011 at 4:01 AM
Edited Oct 27, 2011 at 4:12 AM

I'm sure Mr. Jacobi is more knowledgeable than me on this matter but I suspect the scenario is the following :

Vst.Net is using the managed extensions from mscorlib.dll and c++ (unmanaged) and c++ (managed) code is linked in a mixed mode assembly. 

Mono does not support managed extensions of the Visual C++ compiler embedded in a mixed mode assembly.

A work-around could be converting the code compiling the mixed mode assembly to a pure MSIL assembly, although it is very convoluted and some form of communication between the C library datatypes (for the vst sdk) and the managed C++ must be contrived.

Oct 27, 2011 at 6:55 AM


Unfortunately VST.NET is windows only.

See also:

Oct 27, 2011 at 5:38 PM

Ah too bad. For now I'm the only person using my plugin though so its not that big of a deal for me.

Oct 28, 2011 at 6:39 PM


I checked in code that should allow you to build a Clr4 Interop.

See Also:

Hope it helps.

Oct 29, 2011 at 6:36 PM

Thanks! I've got it working without the config file now.

Oct 29, 2011 at 7:36 PM

Cool! Do you use the "Any CPU" managed assemblies or the x86/x64 ones?

Oct 29, 2011 at 10:15 PM

I used the "Any CPU" configuration. Although to be honest I don't totally understand the benefit of using x86/x64. Would their be some performance benefits or something?

Oct 30, 2011 at 12:42 AM
Edited Oct 30, 2011 at 1:13 AM

I wasn't aware of a x64 assembly of so I don't know the benefits of this implementation. The potential performance hit of running a x86 program on a x64 architecture is small. The potential performance benefits of using x64 is higher. All depends on the scenario involved especially with register and memory usage. A typical scenario would be using increased precision floating points registers of the x64, this gives additional quality at minimal processing cost but shouldn't increase performance drastically. ie: 64 bit precision audio data instead of 32 bit with properly implemented buffer loops using 64 bit registers. 


There is something, you can't load a 32 bit library in a 64 bit program. If you depend on 32 bit libraries, you need to compile to x86. Same with x64. Personally I always compile to x86 or x64 (when I don't need 32 bit libraries), never any cpu because it can cause problems down the road when  dealing with external dependencies. ie: you use a x86 library in a Any Cpu program on a x86 architecture, this is fine because Any Cpu is loaded x86 (because of the x86 architecture) and then loads x86 library. But on a x64 system, this will crash because Any Cpu is loaded x64 (because of the x64 architecture) then loads x86 library causing a mismatch.

Oct 30, 2011 at 11:32 AM
Edited Nov 21, 2011 at 3:12 PM

Hi Guys,

Well there is almost no difference between Any CPU/x86/x64 for pure managed assemblies. The only thing that changes with those settings is that they are marked as such but -as I understand it- will not prevent correct execution in other environments. Remember managed assemblies are pure IL and that gets interpreted at runtime. The only reason to set them -to my mind- is if you use (unmanaged?) dependencies that are specifically x86/x64.

For Interop it is a different matter. That is compiled to specifically x86 or x64. That is why there is a Any CPU (x86) and Any CPU (x64). The managed assemblies are compiled for Any CPU the x86/x64 indicates the setting for Interop.

See also:

@Yury: You make a distinction between Win32 and x86. I am (al)most certain they are the same ;-)

While doing the build automation I thought it would be a small effort to provides builds in all flavors.

Hope it helps,

Oct 30, 2011 at 8:26 PM

Ah good to know. All my dependencies are managed assemblies right now so I guess I'll just stick with the Any CPU configuration.