Migrating my projects to JUCE 5 is causing problems on Windows

Hi there!

My project is currently in beta and I was looking forward to release my plugin within the next month. That also means that I’ve got to buy acquire a license I was thrilled to see that the new license model that comes with JUCE 5 is going to scale way better with the growth of new startups. :ok_hand:

When I tried to migrate my project to JUCE 5 last night I was hitting some roadblocks on Windows and had to revert back to JUCE 4.3.

I’m using 5 projects:

  • Static Core Library
  • Static UI Library
  • Core Library test host: Tests the core library using google test and google mock. (Links the Core Library)
  • UI Library test host: Custom test host to test and develop my custom UI components (Links the Core and the UI Library)
  • Plugin: The actual plugin project. There is not that much going on. Most of the implementation is done in the static libraries. (Links the two libraries)

On MacOs I’ve put all my projects into a workspace. This still works fine with JUCE 5. On Windows I’ve got one solution that includes all my projects. This was working fine until JUCE 5 as there was not much going on within the solutions that the Projucer created for each project. With JUCE 5 the Projucer is now creating Visual Studio projects that include all project files and some JUCE cpp files, that need to be compiled with the project. The project on it’s own doesn’t have any structure (filters etc. ). The whole project structure is now placed in solution. That way it’s pretty much impossible to put all my projects into one big solution any more.

Let me define my problem:

(Xcode project) == (Visual Studio Project)
(Xcode workspace) == (Visual Studio Solution)

on Mac:
(JUCE Project) -> (Xcode Project)

but on Windows:
(JUCE Project) -> (Visual Studio Solution)

I’m kind of confused what would be the right way to go right now. I could manage the projects myself, and not use the Projucer at all, but that would make upgrading way more complicated.
Are there any plans to support the old way projects where managed or may to manage multiple projects with one JUCE project?

Can I still acquire a JUCE 4 license in case I decide to stay on JUCE 4.3 for now?

Good question. Do you have any suggestions? We need to be able to have different project settings for different targets - for example - the standalone plug-in target needs to be linked as an executable etc. Is there a way to achieve the different target settings in a single VS project?

Sure, each configuration of a project can have a different type of output binary, see screenshot (it’s VS2015, I hope they haven’t changed that it VS2017)

Hmmm, is there also a way to exclude/include certain compilation units to the build?

i don’t think so - I’ve been looking for that feature also

Yes you can right-click on a CPP file in the project and set “Excluded From Build” to Yes. This can be done per configuration. I think the Projucer already uses that feature to exclude the CPP files inside modules from the build.


cool to know, thx for the info…

Of course, here is a screenshot of the same option that @roeland-2 already described in its post above.

As you can see from the window title, this is a setting that can be specified per file, and for each file it can be also customized per configuration (and platform, should the need arise).

OK interesting. I’ll play around with this and see if this would be a better way to do multi-target exporters.

1 Like

When doing so, please also consider the issues reported by @chkn in this other topic:

Hi everyone,

@fabian: Thx for looking into that. Most other API developers wouldn’t do that.

I could actually deal with the different project (or “targets”), as long as would still be able to create my own solution for all of them. With Juce 4 I was able to manage my projects in the Projucer without messing up my own solution. Now with JUCE 5, I would have to update my own solution every time I save the Juce project as the project structure (Filter/folder, header files) are managed in the solution, not the project. I get the idea of representing targets (in the XCode world) as Projects (in the Visual Studio world), and I actually think it’s not bad at all. Maybe an option to put the project structure back into the main project (That would be the static lib project for plugins ans so on…), would already be enough.

The best solution would be, if I could manage multiple projects (static lib, plugin, command line) in just one Juce project. That way I could get rid of my own solution at all. I know that might be to much work right now.

Btw. it might be off topic, but as we are already talking about the visual studio exporter, I’ve created a JUCE branch for myself and added pre compiled header support to the visual studio exporter. It’s very basic. For all juce cpp files precompiled headers where disabled as they are not including the precompiled header file (I don’t know if that’s the right term, normally stdafx.h).

1 Like

I think it would be great if we could get something like this officially supported

If ROLI is taking a closer look at project organization and exporters, please contemplate a role for vsprops (VS property sheets) and xcconfig (XCode config) files. Folks have been suggesting and requesting this since at least 2011. They provide a mechanism for specifying project and configuration settings that would allow for developer customizations that don’t get blown away every time ProJucer is run (as well as making it easier for folks to still get the settings right even if they don’t want to rely on ProJucer, and generally provide more flexible and powerful configuration management.)


I just updated my Juce to v5 today, and saw this issue of having all source files being placed at the Visual Studio solution level, AND also at the project level without any filters (“folders”).

Apart from the various problems with Visual Studio (so this probably affects most of the Windows Juce users) mentioned by users in this and other threads, I just want to point out how inconvenient and visually unpleasant it is to not have any filters to organize the source files at project level. Why not apply the same Projucer’s Groups to create filters at the project level, just as they are used at the solution level?

I guess this new structure fixes some issue when developing plugins (although some users have suggested alternatives), but for users like me who are developing just a single GUI application, it feels quite disappointing to see the source structure in Visual Studio is so much more inconvenient now than it was with Juce 4.3. Would it be possible to offer an option in the Projucer, to organize the source as it was done in previous versions?