This has bitten me several times and I am wondering what the reason is for this requirement? Is it part of the .MOF specification, a technical issue with the DSC implementation or an arbitrary decision by the DSC team? If it was an arbitrary decision can we petition the team to remove this requirement?
The problems this restriction can cause range from kind of annoying: http://stackoverflow.com/questions/23177212/using-the-file-provider-in-dsc-ensure-destination-only-contains-files-from-sou
to truly troublesome: it breaks the composability of configuration files.
For example, a recent issue I just ran into is that two different configuration resources had a need to append a path to the ‘Path’ environment variable. This resulted in the following error: The key properties combination ‘Path’ is duplicated for keys ‘Name’ of resource ‘Environment’ in node ‘localhost’.
The only real solution to this is to make sure all of the configuration resources are disjoint sets of resource\key pairs. That is not a viable solution for anything but the most trivial of server configurations. This would require that every configuration resource be aware of every other configuration resource, what they are configuring and how they are configuring it. Dependencies would get baked into configuration resources and decisions would have to be made about which configuration resource would be the one responsible for configuring concerns that cut across multiple configuration resources. Reusablity goes out the window because I cannot simply copy a configuration resource from one server to another unless I identify and bring along every configuration resource it is dependent on and their dependencies etc. What is to say I want all the baggage on the new server that those dependencies bring along or that they will not introduce conflicts on the new server. At that point it is not really a composite resource composed of independent configuration resources, it is a monolithic resource split into separate files. That does not have any value. I might as well just combine everything back into a single configuration resource. At least then I would be able to identify all of the conflicts and dependencies more easily.