Brothers In Code

...a serious misallocation of .net resources

I Love Visual Studio's Build Events!

I've been using Visual Studio for more than 10 years, yet I've only discovered build events in the last year.  I really don't know how I survived with out them.

The big push for me was SharePoint.  There's a lot of things to do after you build a project: register a dll, run some stsadm.exe commands, copy some files to the 12 hive, etc.  Doing all this manually started to drive me nuts. 

But build events saved me.  Basically if you can execute your task from the command line, then it can be a build event.

A simpler example involves config files.  In a multi-project solution, I often need to keep multiple copies of a config file - say a dll is used by both a web app and a unit test project.  Keeping these in sync can be frustrating - all of a sudden your unit tests start blowing up because you only changed an expired connection string in the web app and not in the unit test.  I wrote a simple build event to copy the config files from the main project.  I even appended a little note that it was copied by the build event so I remember to edit the main file and not the copy.

There's pre and post-build events and there's lots of "macro" variables that'll keep your build events friendly over multiple developers or PCs.  You'll find the build events tab by right clicking a project file and selecting properties.

B