[quote=274724:@Norman Palardy]Huh
I just ran the IDE as a remote debug session to one of my windows vm
lots of stuff to make sure is copied in a post build step to make this work but it just worked[/quote]
I just filed a Feedback report (case #44434) and a tech support request, hopefully you’ll run into the problem and see what’s causing it.
Can you zip up your plugins folder & attach that too ?
That way I’m using the exact same project, Xojo version & plugins
A couple things I have run into: Sometimes I have to turn off my router then back on again. My Mac gets a different IP address, which I change in the Windows IDE and it works again. have to do that about twice a year.
Also, just tried to run the remote debugger in R2B22 and it says it is from an unidentified developer. Greg acknowledged this was a problem in 2016r1.1, but are you guys still not code signing it? I have to run the one from 2014r2.1 to get it to not complain.
If I put in all MBS Plugins, Xojo loads over 500 dlls. No problem.
If I just put in 29 Einhugur plugins with 100 dlls, I get errors in DebugView.
Some plugins don’t load at all and a lot of messages like this:
[5596] A dynamic link library (DLL) initialization routine failed.
I will do a run on them setting them to /MD if needed.
I do use /MT.
I may move to Visual Studio 2015 and use DLL runtime like Xojo when we can finally ditch Windows XP.
That leaves me confused. Since I had /MT on almost everything. And from Joes post above to avoid static CRT…
/MD is supposed to be the dynamic one if I am understanding it right.
Yes, and /MDd is for debug.
So if I am understanding right or guessing right, then if we were both more or less using the wrong MT then the difference why Christian could load 500 of his and far less of mine would be that his were considerably smaller each one maybe ?
I presume yours consume something which mine don’t 
This thread shows the issues with the plugin SDK and lack of guidance from Xojo as far as best practices. Plugins are the red headed stepchild of Xojo. They want them, sort of, but don’t make it easy for developers to create them. Lack of guidelines, documentation, examples, etc are a problem.
While I generally agree, using the multithreaded DLL is what Microsoft recommends developers use (and has recommended for a very, very long time).
I am still confused !! So what is the conclusion of what we should be using ?
MSDN says the MD is also multi-threaded though.
[quote=274920:@Björn Eiríksson]I am still confused !! So what is the conclusion of what we should be using ?
MSDN says the MD is also multi-threaded though.[/quote]
Norman’s link agrees that /MD is correct.
[quote=274920:@Björn Eiríksson]I am still confused !! So what is the conclusion of what we should be using ?
MSDN says the MD is also multi-threaded though.[/quote]
/MD is the DLL
And that also happens to be multithreaded
The third is the dynamically linked library. This one keeps all the C runtime library code in a separate DLL (MSVCRTxx.DLL). Since the runtime library codes in a DLL, it also handles multi-threaded issues. The DLL library is enabled with the /MD switch.
[i]But Ive been wondering. Why on earth would anyone ever choose any option OTHER than multi-threaded DLL version of the runtime library?
There are LOTS of reasons for always using the multithreaded DLL:
Your application is smaller because it doesnt have the C runtime library loaded into it.
Because of #1, your application will load faster. The C runtime library is almost certainly in memory, so the pages containing the library dont have to be read from disk.
Using the multithreaded DLL future-proofs your application. If you ever add a second thread to your application (or call into an API that creates multiple threads), you dont have to remember to change your C runtime library. And unless youre running the app verifier regularly, the only way youll find out about the problem is if you get a heap corruption (if youre lucky).
If your application has multiple DLLs, then you need to be VERY careful about allocation each DLL will have its own C runtime library heap, as will the application. If you allocate a block in one DLL, you must free it in the same DLL.
If a security bug is ever found in the C runtime library, you dont have to release an update to your app.
[/i]
I just wanted to let everyone know I found out why my app wouldn’t run remotely from my Mac on Windows: A file included in one of the project’s folders had a filename with double quotes (Hanging Card 3" x 5"), and that kept the project from being expanded on Windows.
Now back to the discussion about DLL overload.
Please fill a feedback case. The remote debugger should know how to escape file names.
Its an illegal file name on Windows where unpacking fails to create the file but isn’t reporting it to the IDE
<https://xojo.com/issue/44452>
If you manually try to create such a file using Windows Explorer it comes up and says “A file name can’t container any of the following characters \ / : * ? < > |”
like 
but it is legal on Mac and the IDE could remove the quote character.