Split Visual Studio SharedCode to JuceCode and ProjectCode from Projucer

Feature Requests
1

The Solution would look like the image on the right

projects
projects754×376 86 KB

This has some advantages, and I don’t know of any drawbacks. For me above all it would avoid the pain of searches and refactoring. I think it could have better performance as well, especially with intellisense.

I did the division manually and it works without problem. I just had to remove SharedCode and copy it to ProjectCode and JuceCode, then from ProjectCode I removed JUCE modules, and from Juce code I removed JUCE Library code and AudioPluginDemo. I understand that since the JUCE library is generated as part of the project it must be included with the plugin.

The next thing was to update the dependencies so that ProjectCode depends on JuceCode, and Standalone and VST3 depend on ProjectCode. Also update the output and intermediate folders, as I would get a warning if they shared the same one. On Standalone and VST3 update the same folder for link. And that’s all.

So apparently it’s quite simple, the problem is having to do all these procedures every time I update the project with Projucer.

Could an option be included in Projucer (even if it’s as beta/test functionality) where the visual studio code has this structure?

2

What problem(s) do you have after updating with Projucer?

When I Save Project from Projucer I only have to reload the solution if it is loaded in Visual Studio.

3

I can’t create the structure I want, since Projucer will restore the original structure. Maybe I could create a parallel solution coexisting with Projucer’s, but there would still be discrepancies in the configuration of the projects. In addition to unpredictable consequences that I don’t know about. That is why I request that option.

4

Benefits of Using Visual Studio Projects
https://www.microfocus.com/documentation/enterprise-developer/ed80/ED-VS2017/GUID-802D1D7A-BF87-454F-9808-1227DA0607C9.html

Recommendation :
Create multiple smaller projects in a solution, rather than keeping all code in one very big project. Consider creating one project per functional area of your application.

Benefits :

  • easier to manage

  • quicker to load into the IDE

  • quicker to compile

In addition, keeping your projects smaller helps achieve quicker response times in the editor.

Limit the number of files stored in a single project

Micro Focus recommends that you:

Avoid having a large number of files in a project. Consider adding multiple smaller projects in your solution and avoid using one single project for all the source files.
Consider creating a project per functional area of your application.

It is hard to provide a strict recommendation for the maximum number of files to store in a single project. This number will depend on many factors related to your particular development scenario such as:

  • Size of the files and of the programs

  • Number and size of any copybooks

  • Number of people working on the same project

  • Whether the project is a .NET COBOL or a native COBOL one

  • Whether your applications use incremental linking

  • The existing structure of the source code

Keeping the size of your projects smaller helps avoid various performance issues. As the size of a project increases you need to be aware of issues such as the following::

  • The poorer the user experience inside Visual Studio

  • Find All References works slower

  • The project is more difficult to manage

  • The longer the times to load and rebuild the project

  • The longer the times to perform background syntax checking, code analysis, or to scan files for Compiler directives (using Determine Directives).