when people first get their hands on msbuild, especially those familiar with other build systems, one of the first things they notice is msbuild's dependency analysis mechanism.  the msbuild engine offers basic dependency checking based on explicitly declared target inputs and outputs.  currently, the analysis is pretty simple, although helpful in many cases:  msbuild checks output timestamps and input timestamps and if some of the outputs are older than some of the inputs (i'm glossing over details here), the engine will execute the target.

users of other build systems have pointed out a fairly obvious limitation of this mechanism:  dependency analysis often must be more complex than timestamp checking.  i couldn't agree more.

however, this limitation of msbuild's dependency checking mechanism should not be mistaken for a limitation of msbuild itself.  reason:  the author of a project file is not strictly limited to using the msbuild engine for her dependency checking, nor is she required to allow the engine to perform any dependency analysis at all!  furthermore, and most importantly, this mechanism (whether opting in or out) in no way precludes tasks from performing their own dependency analysis at any level of precision they'd like, exactly as many (N)Ant tasks do today.  the resgen task our team has developed does just this.  we found in some cases simple filestamp checking would lead to skipped calls to resgen when they were actually required, so we simply moved the dependency analysis from the target level to the task level and voila! problem solved.

all this still leaves room for the engine to do more complex analysis while still exposing more control over it to the user, and we're thinking hard about how to make that happen.

jeff.