Provide ability to define dsc-v3 resource path (Support sxs installation)

[BerheAbrha]

Summary of the new feature / enhancement

dscv3 is relying on system variable ($env:path) for resource discovery. Provide an ability to specify the directory for all dscv3 resources.
- This will enable sxs installation possible. (GC-Agent supports this)
- DSC is slow locating resources since it is checking a big list of paths in $env:path.

Proposed technical implementation details (optional)

Pass optional DSC_Resouce_Path to DSC .
No response

[michaeltlombardi]

One workaround for this (which I've used in the past) is to override the PATH variable in the process that's running DSC. Higher order tools may want to do this anyway, even when the user isn't specifying an alternate path.

[anmenaga]

1. good idea about having an ability to overload %PATH% with custom location with resources;
2. By itself DSCv3 resource enumeration performance is actually quite good at this point; what makes it look slow is PowerShellGroup resource / PSDesiredStateConfiguration module. There are ways to disable it, for example rename it's json to not end with dsc.resource.json.

[SteveL-MSFT]

If GC-Agent is spawning dsc, it can set the PATH in the env block of the new process to constrain it's search and allow for side-by-side

[BerheAbrha]

Overwriting the system $env:path in the process may impact locating executable or other resource dependencies that are already under $env:path

[Bpoe]

I agree with BerheAbrha. Resources called and the processes spawned calling those may depend on PATH being intact. We will need to support either specifying the search path(s) as an argument or support another ENV var that would be used if specified instead of PATH. (Think something similar to PSModulePath)

[SteveL-MSFT]

We can have a DSC_RESOURCE_PATH env var that, if defined, overrides any search of PATH.