1

We have a very complicated multi-stage build system:

  1. Auto-generate a ton of C# from XML.
  2. Compile C# with Visual Studio.
  3. Post-compile non-Microsoft-native languages like Sass and JavaScript.
  4. (...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?

Sean Werkema
  • 5,810
  • 2
  • 38
  • 42
  • You might be able to [disable the caching](http://stackoverflow.com/questions/2903803/how-can-i-prevent-external-msbuild-files-from-being-cached-by-visual-studio-du) and have things work like you want. – Quantic Dec 21 '16 at 21:43
  • I'm looking for a solution that's a little sturdier than "maybe you could try" answers. I've experimented with the answer at that link, and a few others that I found on StackOverflow, and none that I've found seem to work well enough to be usable for us. – Sean Werkema Dec 21 '16 at 22:00
  • How about, after generation, an nmake project in your (parent) solution executes msbuild on the distinct (child) solution/project that you generated? – asynchronos Dec 22 '16 at 18:10
  • The .csproj and .cs files are not _fully_ generated; some are created manually, and the code generator updates and adds files as necessary. (The .cs files make heavy use of `partial` classes, and our programmers know not to edit anything with a `.generated.cs` extension.) So the .csproj and .cs files can't exist fully outside Visual Studio either, just managed by `msbuild` and `nmake`; they have to be normally-editable as part of the Solution too. – Sean Werkema Dec 22 '16 at 20:33
  • msbuild can build visual studio projects. So I think you could still have a distinct child project/solution containing some generated and some manual content, which you kick off after generating in a parent solution. I realize two VS solutions isn't as great as one. – asynchronos Dec 22 '16 at 23:43

0 Answers0