DscBuild: Restore state of Program Files directory on failed build

[dlwyatt]

Right now, the first thing Invoke-DscBuild does is delete any modules in C:\Program Files\WindowsPowerShell\Modules if they have a different version than what's about to be tested and packaged.

If the tests then fail, those modules are now missing from the build server until the next successful build. This might cause problems if DSC is being used to manage the build server itself.

Two possibilities here:

• See if we can test and package the modules (and compile configs) from a location other than the system-wide PSModulePath. Not sure if this is viable, due to the way Import-DscResource works, but it's worth investigating as a preferred option.
• Instead of deleting the original module copies, just move them, and move them back if the build fails.

[dlwyatt]

Come to think of it, even on a successful build you may not want to be changing the state of the Program Files folder on the build server. If its DSC config is using specific versions of the resources (and isn't ready for the updated version yet), that could also break things.

[tysonjhayes]

Isn't there a bug in PS 4.0 that basically says you have to put them in the ProgramFiles in order to read it though? They fixed it in 5.0 if I'm recalling this correctly. I think the idea of moving them (and then moving back) makes perfect sense to me.

[dlwyatt]

Not sure yet if they have to be in Program Files, or if it's enough to be just somewhere on the PSModulePath. Will investigate. :) Would be awesome if we can just prepend a temporary folder to the PSModulePath environment variable (process scope) when compiling the MOFs, so we don't have to mess with the modules used by other processes.

[smurawski]

@tysonjhayes @dlwyatt In PowerShell 4, they have to be in Program Files for the LCM to find them. This shouldn't impact where we place them for build/test though. That was just the most expedient way for me to do it at the time.

What we should do is isolate psmodulepath to a known location for processing the resources under test. We want to do that so that we can avoid having other modules accidentally resolve during specific tests.

[dlwyatt]

This seems to work fine. I've tested it on WMF systems both with and without the rollup. When I assign a value of "$someTempFolder;$pshome\Modules" to $env:PSModulePath, Get-DscResource finds everything that we need it to, and Import-DscResource and MOF compilation also work fine. This makes things quite a bit simpler.

So, user experience:

• Invoke-DscBuild will, at a minimum, temporarily add a new folder to the PSModulePath (the -SourceResourceDirectory directory), and will do all of its testing, compilation and packaging from there.
• Should Invoke-DscBuild also clear out all of the other paths, aside from $pshome\Modules? What if the build needs some additional dependencies in order to work? At the very least, it's going to need to be able to import the module specified by -ConfigurationModuleName, wherever that resides. Should the user be able to specify other folders that are also kept in the path during the build, perhaps via a new parameter to Invoke-DscBuild? (If we don't bother with this in the module, then the caller can decide what to do with the PSModulePath before calling Invoke-DscBuild.)

[dlwyatt]

The pull request currently assumes the first option; just prepend the PSModulePath with the SourceResourceDirectory, and run the build. Callers can optionally remove some of their default PSModulePath entries before calling Invoke-DscBuild if they want to, but it's not a requirement.