A project has a LOT of .xxx source files. There is a tool that will read one ABC.xxx file and write out ABC_1.cpp, ABC_2.cpp, ABC_1.hpp, ABC_2.hpp, ABC_3.hpp

Each of those two .cpp files uses each of those three .hpp files, producing .obj files to go into a .lib file (to be used in a later part of the very big project). In addition, some other .cpp files (that are true source code, not generated) also use some of those .hpp files.

Do you know of any cook book instructions and/or tutorial to the process of getting Visual Studio to have those rules, such that a .xxx file can be put in as a simple source file to the project and each time that .xxx file is changed, all the rest just happens on the next rebuild.

I'm used to sane build tools like bjam, where such things just work that way. I'm not doing any of this myself, nor do I really have the patience to learn it. But I am advising people who are doing it, and cook book instructions and/or a tutorial would be great things for me to tell them to read.

Whatever part of the Visual Studio documentation covers this stuff seems to be clear as mud.

I guess it depends how big of a project you have and how many different things are included. For me I usually just do Windows Forms apps. I don't pay attention to every file. To archive, I archive my entire project directory and I don't find them to be huge. I also don't find that doing a clean necessarily makes it tinier either.

As far as organization, you can sub-directory your sources and organize resources the way you want. You don't have to follow how they set it up. I rename files that they put in. I also add C## sources and make them what I want them to be named. So if I add a COM Settings Form I name it that. My main.cs should not be named that, if my application is Data Sorter, then I rename the main.cs to be Data Sorter Main Screen.cs. As I add more sub-functions to my project, I do the same thing. I'll have a receiver, a set of COM utility functions, then like COM settings, and About for the About form part of the project. One for Menus, one for Slots or Methods. I do stay within Visual Studio. I've worked for years using "alternative-ware" compilers where I've found that they don't quite keep up with uSoft and as a result I'll have customers who have 10, the latest and then get frustrated that my toolkit doesn't conform. Yeah, we can blame uSoft, but Apple is just the same. So I stay within XCode for iOS. Extra work, but it helps to maintain a good project.

Unfortunately I don't have any automatic means for that or something I've used for very, very large code projects. Some of mine are pretty big, but in the end they are one main form and several sub-forms in support of the one application I'm writing.