We have spent significant time explaining the benefits of code reuse, avoiding duplication, and improving maintainability by writing clean code throughout this book. If DSC composite resources enable these things, then how could there be a section with drawbacks in its title?

In the original WMF 4 release, you couldn't use the DependsOn property to express a dependency between two DSC composite resources. You could use DependsOn inside the DSC composite resource in a normal manner but could not link two DSC composite resources together. This has been corrected in the WMF 5 release. The fix was backported to the latest WMF4 release.

DSC composite resources were sometimes hard to develop. Iterative development (some call this trial and error) was painful as DSC would cache the any DSC resource, and it seemed like it never let go of the DSC composite resources. Make a change and copy the new DSC composite resource and you could spend a lot of time hitting your head against the wall while your configuration runs fail, only to remember about the cache and have it work wonderfully when you reset it (refer to the next section for more on how to remedy this). Some of this is alleviated in WMF5 with the advent of the DebugMode setting for the LCM (we'll look at this in the Debugging and troubleshooting configuration script files section).