Visual Studio Toolset for Windows 10

I need someone to mentor me on Visual Studio builds for Windows 10.

My product “Fathom Synth” has several thousand users worldwide at this point, but I continually have problems with the Windows VST plugin not being detected by hosts in Windows 10.

Currently I am building in Windows 7 with Visual Studio C++ 2012 Express using the Platform Toolset "Visual Studio 2012 (v110)”, not the Windows 7 SDK.

The issue is complicated because I have had to provide my customers with two different versions of my plugin. One built with Runtime Library set to “Multi-threaded DLL (/MD)”, and the other with the same option set to “(/MT)”.

The MD option dynamically links at run-time with the necessary Windows libraries on the user’s target system, and the MT option, of course, statically links the libraries into the DLL.

I have found through considerable experimentation in the field that generally the MD option is better and works with the majority of target systems and hosts, since it links dynamically with the same libraries used by the host on the target machine.

But my Windows 10 users often have to use the MT statically linked build because the MD build will not be detected at all on their system when the host scans for plugins.

I myself as a user have never seen a plugin manufacturer have to provide different builds of their plugin for Windows, so I know I must be doing something deeply wrong.

I do have a Windows 10 partition, so I can actually build my product in Windows 10, but that does not seem to have any effect. Also, unfortunately, I cannot yet afford to use the latest Visual Studio, so the solution I hope can be found in one of the cheaper VS options.

Can one of you who have been in the plugin market longer than I please offer some advice on how it may be possible to provide a single Windows build. One that is easily scanned by all hosts…

Thanks so much!

Do you qualify to use the free Community Edition of Visual Studio? (You may qualify even as a business if you have revenue below some limit.)

By the way, the easiest option for the technical issue is to just statically link the runtime libraries, regardless of Microsoft recommending the dynamic linking and their aggressive push for developers to adopt that. I don’t think you will necessarily get any benefit by dynamically linking. There is no guarantee your plugin will actually share the runtime dll with the host. Hosts may themselves use static linking of the runtime or an incompatible version of the dynamically linked runtime.


Good point. I’m using the free version of VS 2012, I’m not sure of one of the later versions of VS is yet free, but it might be worth a try.

However, my guess is that the tool set or build options problem would probably remain to be solved regardless of the version of VS. Though I am grateful for any advice and willing to experiment, as I have users that could try it.

Good suggestion on defaulting to MT, but interestingly that is exactly how I had it to begin with, the MT static link build was my default release, and in that case the problems were even worse in the field, I had far more users with hosts that would not scan the plugin than with the MD dynamic link build.

Are you maybe using some external libraries that have been built with the dynamic runtime enabled? I have had zero issues statically linking myself. (I do use Visual Studio 2017, though…VS2012 is pretty outdated by now and if I recall right it also had lots of issues and back in the day I was very happy to update to VS2013.)

Goodness, you only have to release one version of your plugin using MT, wow that would be brilliant, maybe the problem is I’m still using 2012.

I wonder if there is a free option for one of the later versions of VS.

Which toolset are you using? SDK or (v110) ?

Of course it’s possible the users who didn’t even get my plugin scanned in their hosts never bothered to report that… :wink:

The toolset I am using is v141.

Very interesting, and I would expect you probably have Win 7 users still also. It looks like I’m just going to have to invest in VS 2017, I wish there was an express option.

OK, Thanks so much for your advice. My users thank you also! I will do some digging and see if there is a 2017 option.

There is a free version. It just stopped being called Express a long time ago:


Thanks so much!

By the way, if one user’s DAW can’t find your plug-in with dynamic linking, that just means that he has to install the Visual Studio Redistribuable associated with your version of Visual Studio. You can provide the link to get it on your website, or put the executable into your plug-in installer.

1 Like

Indeed! Or use VS2017 and it should come with the system :wink: