Best way to manage generated code in an automated build?

Question

In my automated NAnt build we have a step that generates a lot of code off of the database (using SubSonic) and the code is separated into folders that match the schema name in the database. For example:

• /generated-code
  • /dbo
    • SomeTable.cs
    • OtherTable.cs
  • /abc
    • Customer.cs
    • Order.cs

The schema names are there to isolate the generated classes that an app will need. For example, there is an ABC app, that will pull in the generated code from this central folder. I'm doing that on a pre-build event, like this:

del /F /Q $(ProjectDir)Entities\generated*.cs

copy $(ProjectDir)....\generated-code\abc*.cs $(ProjectDir)Entities\generated*.cs

So on every build, the Nant script runs the generator which puts all the code into a central holding place, then it kicks off the solution build... which includes pre-build events for each of the projects that need their generated classes.

So here's the friction I'm seeing:

1) Each new app needs to setup this pre-build event. It kind of sucks to have to do this.

2) In our build server we don't generate code, so I actually have an IF $(ConfigurationName) == "Debug" before each of those commands, so it doens't happen for release builds

3) Sometimes the commands fail, which fails our local build. It will fail if: - there is no generated code yet (just setting up a new project, no database yet) - there is no existing code in the directory (first build)

usually these are minor fixes and we've just hacked our way to getting a new project or a new machine up and running with the build, but it's preventing me from my 1-click-build Nirvana.

So I'd like to hear suggestions on how to improve this where it's a bit more durable. Maybe move the copying of the code into the application folders into the NAnt script? This seems kind of backwards to me, but I'm willing to listen to arguments for it.

OK, fire away :)

Answer 1

We have two projects in our solution that are built completely out of generated code. Basically, we run the code generator .exe as a post-build step for another project and along with generating the code, it automates the active instance of visual studio to make sure that the generated project is in the solution, that it has all of the generated code files, and that they are checked out/added to TFS as necessary.

It very rarely flakes out during the VS automation stage, and we have to run it "by hand" but that's usually only if you have several instances of VS open with >1 instance of the solution open and it can't figure out which one it's supposed to automate.

Our solution and process are such that the generation should always be done and correct before our auto-build gets to it, so this approach might not work for you.

Answer 2

Yeah I'd like to take VS out of the equation so that a build from VS is just simply compiling the code and references.

I can manage the NAnt script... I'm just wondering if people have advice around having 1 NAnt script, or possibly one for each project which can push the code into the projects rather than being pulled.

This does mean that you have to opt-in to generate code.

Answer 3

How often does your DB schema change? Wouldn't it be possible to generate the database-related files on demand (e.g. when the schema changes) and then check them into your code repository?

If your database schema doesn't change, you can also package the compiled *.cs classes and distribute the archive to other projects.