Invoke-DscBuild tests all modules in the Program Files path about dsc HOT 7 CLOSED

It should be more granular. One problem is that Test-DscResource has to be able to find the resource, which means it needs to be on your path, and if you are using V4, it HAS to be in either $pshome/modules or $env:programfiles/windowspowershell/modules. V5 doesn't have that issue. As long as it is on the system path for PSModulePath, it's a valid location.

That doesn't solve the problem of Test-DscResource, which would need to be modified to target stuff outside psmodulepath.

from dsc.

Test-cDscResource can be passed a folder path instead of a module name, and the folder path doesn't have to be in PSModulePath. It only falls back to using Get-DscResource if the value you pass in fails a Test-Path.

However, the current implementation of Where-DscResource and Get-DscResourceForModule would need to be changed in order to support this. Instead of this:

            $AllResources = Get-DscResource |                 Where-Object {$_.implementedas -like 'PowerShell'}

We would need to identify resource paths without using Get-DscResource (probably by just looking for the DSCResources\ path where .psm1 and .schema.mof exist.)

from dsc.

Schema.mof definitely, but since you can have binary modules, can't count on .psm1

from dsc.

@dlwyatt if you have cycles.. modify away!

from dsc.

I'm not quite ready to do that yet. :) I'm still learning about the modules, and setting up an Azure environment where I can test them. I submitted this issue based on reading (but not executing) the code, plus our Twitter conversations with Jacob over the past couple of days.

Once I've got my configurationdata / configuration samples set up and can run a full test of Invoke-DscBuild, I'll start to work on this issue (assuming someone else hasn't taken care of it already.)

from dsc.

Dave Wyatt, you are the man

from dsc.

Already fixed in the development branch.

from dsc.