Best Practices for Creating/Extending Projects Using Projucer and MS VS 2017

The Projucer
1

DISCLAIMER: This may be more of a Visual Studio question than a Projucer question, but any assistance would be appreciated.

SUMMARY OF QUESTION: What is the best practice for creating/extending a project with Projucer, using MS Visual Studio 2017 as the export target? Specifically, should I be adding source code only from within the Projucer and not from inside the MS VS2017 solution after the original export?

DETAILS:

So… I have been working with JUCE for a few weeks now and have been able to create demos with relative ease, following the tutorial write-ups. I asked a question on this forum previously about how to get a Projucer-exported project to link to my external (non-JUCE) code, which was swiftly answered here (thanks again Alassandro!) and subsequently implemented on my end without issue.

With that obstacle out of the way, I’ve been attaching my own external classes which are working, but I’ve noticed when I try to create new classes from within Visual Studio, that VS seems to be ignorant of JUCE modules. For example, I wanted to create a class that inherits from ThreadWithProgressWindow, but MS VS2017 couldn’t find the base class.

My work-around has been to create blank source files, write the class structure and contents manually, then save the file and add it to the JUCE project’s “source” folder from within VS2017, after which point, the VS2017 solution seems to have an awareness of ThreadWithProgressWindow, allowing me to now inherit from it.

I see there is a way to add new source files to existing JUCE projects from within Projucer, but from what I’ve read, taking this approach may overwrite my VS2017 solution, eradicating all of the external source files I’ve painstakingly added to the VS2017 solution and subsequently organized and included so that the JUCE main component can work with my external classes.

Surely there is a better way to go about all of this. I feel like I have some fundamental misunderstanding about how the Projucer works with MS VS2017. Any enlightenment, or pointers to documentation that will explain this better than the tutorials and Projucer help documents have done so far, would be much appreciated!

Thanks for taking the time to read this, and thanks in advance for any and all assistance in this matter.

-David

2

Hey,
I had a similar issue at some point. I had my own external library (Audio ToolKit) and I had to manually include the headers, link it…
In that workflow, you are better with updating your VS solution. But you more or less can’t change your JUCE version!

For me, I moved my library to a JUCE module, so it is “statically” linked instead. It was a little bit painful to create all the sub-modules I wanted, but they are now selectable in the Projucer, so the benefits far outweight the pain of having to start from scratch. And I can update JUCE as well without fearing everything will break.

1 Like
3

Thanks for the insights and advice, Matthieu! Converting everything to JUCE modules sounds like a daunting task. I may eventually go down that route, but for now I’ll continue to do everything manually from within VS as you suggest.

4

I use the Projucer to create the initial project, change project settings, and to add or remove files from the project. Everything else is done in VS2017.

This keeps the project JUCE compliant while actually doing development in VS2017 and being able to take advantage of the tools there (Intellisense, etc.).

1 Like
5

Thanks for your input! That sounds like a good strategy.