I'm developing a .Net application that uses google protocol buffers. Historically the application used the approach, advocated by the protobuf-net team, of decorating the classes with attributes instead of using .proto files.

I am now in the process of migrating part of the application's client to another technology and there is a strong desire to start using the .proto files as the authority so that the two technologies can inter-operate.

My plan is to automatically generate the C# from the .proto, however, my question is should I check the resulting files back into source control? Note I expect the process of code generation to be fast.

How do I choose appropriate approach for above case? What is considered the best practice?

As a general rule, generated files do not belong in the source code repository.

The biggest risk you run when you do put those files in the repository is that they become out of sync with their source and the build runs with different protocol buffer files than you would think based on the .proto files.

A few reasons for deviating from the general rule are


Your build environment can't handle the additional build step automatically. If you have to generate the files by hand for every build anyway, you might as well put them in the VCS. Then it actually reduces the risk of a version mismatch due to fewer people having to do the generation step.
The generation step significantly slows down your build
After generating them, the files are further modified by hand. In that case, they are not really generated files any more and thus belong in the VCS.
The source files change very rarely (e.g. they come from a third party that only provides updates every few months or so).

