Solved Projecttool - avoid updating all projects

In Visual Studio I have added per plugin a custom post-build-event. This copies the resources and compiled plugin file to its specific location, overwriting the previous build. Using this setup, I can include the plugin path in Cinema 4D, which will then load the copied plugin.

However, when adding a new plugin to the projectdefinition and using the projecttool, all project files are updated and these custom steps are lost. Same for the folders/filters I create to organize the different source files in each plugin.

Is there a way to skip/avoid updating some plugin projects, without removing them from the projectdefinition file, as I still want these plugins part of the main Visual Studio solution?

This is strange. I'm using the same Post-Build event with VS and the commands are kept intact when running the project tool over it. Same goes for custom Macros and Debug-options.

Just launched the projecttool again ... custom settings are overwritten once more.
Am I using an old version of the projecttool maybe?
Or should I remove the "g_updateproject" argument?

Also, I keep a backup of the plugin (source, res and project folders) in a subfolder of the plugin.
Obviously, the projecttool does process all subfolders. As such my backups are also updated.
Any change to set up the projecttool to ignore these subfolders?

Well, it turns out I was using an "old" Project Tool. Went over the documentation once more and downloaded the latest version. Ran it ... and custom settings (post build, source folders/filters, ...) all gone, again.
Fortunately, the debug options (location to cinema executable and g_alloc=Debug) remain as is. So, at list not everything gets cleared.

Apart from that I don't see what I am doing wrong, just launching the projecttoo.bat file containing:

d:\Projects\dev\SDK_R20\projecttool\kernel_app_64bit.exe g_updateproject=d:\Projects\dev\SDK_R20

Edit: going over the documentation again since months, I now see that removing "g_updateprojects", as mentioned in my previous post, would have been rather silly.

Hi Daniel, thanks for reaching us ;)

With regard to your issue, although there's no option at the moment to include in the projectdefinition.txtto exclude a certain project from being rebuilt, what I suggest is to just run it over the project you need to rebuild rather than on the whole solution folder.

To be more clear, give the current SDK structure:

<Cinema 4D>
    |-corelibs
    |-...
    |-sdk
        |-frameworks
        |-plugins
            |-cinema4dsdk
                |-project (this contains the project)
                |-source
                |-...
            |-maxonsdk
            |-microsdk
            |-project (this contains the solution)

you can run:

• kernel_app_64bit.exe g_updateproject=<Cinema4D>/sdk : to create/update frameworks/plugins
• kernel_app_64bit.exe g_updateproject=<Cinema4D>/sdk/plugins/ : to create/update all the plugins
• kernel_app_64bit.exe g_updateproject=<Cinema4D>/sdk/plugins/cinema4dsdk : to create/update only the cinema4dsdk project

Last but not least running kernel_app_64bit.exe g_updateproject=<Cinema4D>/sdk/plugins/cinema4dsdk or kernel_app_64bit.exe g_updateproject=<Cinema4D>/sdk/plugins/cinema4dsdk/project has the same effect

Looking forward comments on your side, give best.

Riccardo

Hi Riccardo,
At first sight I thought "but of course, why didn't I think of that".
But on second thought, the whole purpose of running the Project Tool is because I need to add a new plugin to the solution.

So, I actually don't need to update a single plugin project, but need to update the solution project ... well, I mean, the project containing the solution.
As far as I have understood I would these need to run the Project Tool on /plugins/ which will thus update all plugins' projects.

Hi Daniel,

if you'd like to add a new plugin (<Cinema 4D>/sdk/plugins/plugin_X) to your solution without touching the other plugins' projects you can:

• create the folder structure for plugin_X
• create the projectdefinition.txt in the project folder of plugin_X
• run kernel_app_64bit.exe g_updateproject=<Cinema4D>/sdk/plugins/plugin_X in order to create the corresponding project file for the plugin_X
• modify the projectdefinition.txt in the project folder of plugins to include the plugin_X in the solution file
• run kernel_app_64bit.exe g_updateproject=<Cinema4D>/sdk/plugins/project in order to update the solution file.

Obviously this is approach can also to work when it's needed to update any other single plugin or only the solution.

Hoping it makes sense, feel free to come back with further comments.

Best, Riccardo

@r_gigante
Thanks for this. It ticks all the boxes for me.
Although I had hoped for a solution with less batch files, I now understand it's better to have separate batch files per plugin. And one for updating the project solution, without updating every plugin.
So obvious it's embarrassing, but some... ,ok, most times I need someone else to show me the obvious.

Still wondering about @mp5gosu 's answer.

Thanks again Riccardo.

Hey there. I was not quite right about the Post-Build Script.
Years ago I started using an extension that configures my solutions before every run. Looks like I simply forgot about that.
However, it automatically sets the event on every run.

Sorry about the confusion. :)

@mp5gosu
Thanks for the clarification.

But since we are talking about that, I'd file a feature request.
It should be possible to define portions of the solution that should not be overriden.

I have filed a feature request in our development.
Cheers,
Andreas

Hi,

there are two more approaches, we discussed when suggesting this request to our development.

a) So obvious, we should have come up with in the first place and you probably already considered yourself: Use of your diff tool. Before running the project tool, save the old project files and afterwards use the diff tool to carry over the manual changes. I know, still cumbersome.

b) Maybe .props files can be put to use here. These shouldn't be touched by the project tool.

Nevertheless, it will also be considered to tackle this issue inside of the project tool.

Cheers,
Andreas

@a_block
I am not so in favor of solution a) and as for b) I am no expert when it comes to props files. Someone will need to teach and tutor.
Still, I appreciate the suggestions.

Here's an older blog post about VS property sheets. Still for VS2010, but the principle is still the same.
Sharing project properties in Visual C++