We have a very complicated multi-stage build system:
- Auto-generate a ton of C# from XML.
- Compile C# with Visual Studio.
- Post-compile non-Microsoft-native languages like Sass and JavaScript.
- (...more steps for database-oriented things...)
Importantly, in the first stage, a set of short XML files are transformed into C# files. Various .csproj files are automatically updated to add any new C# files that were generated, and to remove any C# files that are no longer relevant.
This has been the way our software has been built for many, many years, and it has been a big, big win for us. More than a million lines of our code are automatically generated from only a few thousand lines of XML: Our overall design of using custom code generators definitely isn't going to change!
However, the code-generation process lives outside Visual Studio, as a manual step. We'd really like to integrate the code-generation process into the standard Visual Studio build.
Our plan was to have the code generation run as a pre-build event on an otherwise-empty .csproj file, and it would generate the next .csproj file before Visual Studio had a chance to get to it (using Dependencies to control build order).
Unfortunately, Visual Studio's build-caching logic defeats this: One .csproj apparently can't modify another .csproj file during the build, because Visual Studio caches the second .csproj file's contents.
Visual Studio complains loudly if you try, with delightful inscrutable error messages and general glitchiness.
So is there a way around this? Is there a way to have substantial C# code generation as part of a Visual Studio build?
Or are we stuck with having it as a separate, manual process outside Visual Studio?