When i run it i get the following message:
Import-Module : The specified module ‘Pester’ was not loaded because no valid module file was found in any module directory.
I am using Powershell v4 on Windows 2008 R2. Do i need to change provide the full path to the modules or am i missing something?`
Do i need to manually copy Pester,dscbuild,dscconfiguration to “C:\Program Files\WindowsPowerShell\Modules”
On target nodes, DSC resources need to be installed in one of the folders listed in PSModulePath, usually C:\Program Files\WindowsPowerShell\Modules. However, given the folder hierarchy you’ve shown, I don’t know what you’d copy. A DSC resource module must have at least a root .PSM1 file, and then a DSCResources subfolder, which I don’t see anywhere.
Everything that’s in your DSC_Tooling folder should exist in your PSModulePath (probably \Program Files\WindowsPowershell\Modules’ ) before you run Invoke-DscBuild. You would also need the SampleConfiguration module from the Tooling\Examples\ folder of the DSC repository in that location as well.
If you want to actually execute the sample build, you will need the StackExchangeResources, cWebAdministration and cSmbShare modules; those should be placed into your DSC_Resources folder, which will cause the Invoke-DscBuild command to test them and to produce zip files / checksums for them.
When we set up the TeamCity pipeline for DevOpsGuys, we created two steps. One was to install the dependencies (tooling modules, Pester, certificates needed for credentials encryption), and the second was to actually run Invoke-DscBuild. That first “install dependencies” step isn’t part of the DSC repo’s examples yet, but I’ll ask if it’s okay to share that as well.
On a side note, I haven’t really used the DSC_Tooling portion of Invoke-DscBuild yet, and I’m not sure what Steve’s use case for that was. I’ve been meaning to ask. It seems like a bit of a “chicken or egg” situation, since you need many of the tooling modules before you can run Invoke-DscBuild. That’s why we created a separate “Install Dependencies” step in TeamCity.
Whoops, good catch. PowerShell converts $null to an empty string; that’s a common gotcha.
I think it’s probably a good idea to get rid of the arguments to the module itself; most people don’t even realize they’re there, and auto-loading the module misses that point anyway. That parameter would be more discoverable and intuitive in the commands that need to use the certificate. (You can already control the ConfigurationDataPath that way.)