After discussions with a junior co-worker about build events of a C# project, I realized it was a good example of how people who have not worked in Enterprise type situations pigeon-hole themselves in the problem they are trying to solve and sometimes their solution might need rework later because they are not aware of the possibilities that might arise when the business scales up. This is related more to experience and strategic thinking than technical expertise. I guess that is why Enterprise-level experience should be valued in the industry.

To illustrate this, let me talk about a specific problem and it’s possible solutions.

Deploying a document (Word, XML, etc.) as part of an application is a common need and there are multiple ways to do it. People seem to jump to using build events for this. FYI, this is done by adding a post-build event (in the project properties) to copy the required Documents to the target location. Unfortunately this approach could introduce limitations to the SDLC of the product in question, as explained below. I say “could” because it depends on the situation at hand.

If this document is more part of the deployment process or the development or build process, it might make more sense to make it part of an installer package rather than adding build actions.

If the document is needed for debugging, an argument I see is that developers need not run an installer to be able to debug the project in question. They can just get the latest code and they’re ready to debug because the build process will put the docs in the right place. Sounds good at first glance but may not be.

Here’s the problem. Suppose the company or project really grew big and needed a large number of documents and a team of editors to manage them, we have introduced a bottleneck because only the build process makes the documents available to the world. So essentially even fixing a typo would need a build process. You get the idea.
So, the right solution would be to make the Templates part of an installer and have developers run the installer as part of their environment setup. Now, if the overall application is huge, the Document installer can be separated out and run as part of a bigger installation. This smaller installer can be run for dev as well.
Having said that, it might be ok to not require an installation process for dev and instead (additionally) add a post-build action to ease the development process but I would look at this very carefully.
On the flip side, in case the document is highly development oriented e.g. an XML doc with metadata or config info., then build actions might be suitable for getting the job done and an installer might merely package files as they are.

Hope all that makes sense.