I am glad to see other developers as curios and un-afraid as myself!
Not to kick a dead horse. None of what is being said here is foreign to me. But I am anal about being thorough, even is a forum post.
The WindowsDLL does in fact build under Visual Studio 2017. I have no idea why Xenakios cannot build it. Perhaps it is ‘Site Specific’.
I did this:
Within the project change:
Configuration Type: Dynamic Library (.dll)
Linker->General Output File: change juce_dll.lib to juce_dll.dll
Start a command prompt (cmd)
(Because 64 bit compile tools are required, one is probably running 32Bit) from a command line:
cd C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\Tools
-One must ‘Clean’ the project because you probably attempted it with 32Bit tools
MsBuild WindowsDLL_StaticLibrary.vcxproj /property:Configuration=Debug;Platform=x64 /t:Clean
MsBuild WindowsDLL_StaticLibrary.vcxproj /property:Configuration=Debug;Platform=x64
So, it builds successfully. Whether or not it is usable is another story.
Some statements. Feel free to correct any incorrect statements:
1.) The WindowsDLL project is there to test the building of the juce code that actually utilizes JUCE_DLL_BUILD.
2.) The only code within the JUCE code base that utilizes JUCE_DLL_BUILD is represented by the projects identified under ‘JUCE Library code’.
3.) Note the missing modules.
Jules, I would suggest one does not remove the WindowsDLL from the CI as there are still adventurous soles out there. Perhaps a readme is enough for clarification of it’s purpose. One should of course include verbiage such as ‘If you are brave enough, this is not supported, you are on your own, please do not post to the forum questions,…’