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.
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:
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.
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.
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.
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.
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++