Overloading Usage of PSCmdlet

DSC
1

I’ve created a DSC Custom Resource in C# that will be used to help deploy our product (it’s the first of several as we have some complex configuration files that need to be rendered). As I am working out the DSC solution, however, we continue to deploy manually to customer sites (using an .msi and then manually editing configuration files). Obviously, that’s not in the spirit of automation, and we do get frequent mistakes.

I would like to use the same code and deploy as a “standard” PowerShell cmdlet, so that I can sign it and use it on a customer’s machine the old fashioned way. The Get/Set/Test naming convention for the DSC class is not going to be pretty for this purpose, and there are several folks doing the install that aren’t necessarily PowerShell saavy, so I need to make this as transparent as possible.

Is there a way to reuse the code as both DSC & traditional Module, and still preserve the PowerShell attributes (i.e. I lose WriteVerbose unless I inherit from PSCmdlet)? Or is it considered better form to just duplicate the code base (a developer’s no-no)?

2

Yeah. And honestly, you’ve seen it already in most of what Microsoft does. Resources rarely contain “functional” code; they’re an interface layered on top of cmdlets.

So: Write cmdlets that actually “do” stuff. The Resource should just “coordinate” the process by running cmdlets. This might be as simple as writing a Test-xxx cmdlet to check your config, a Get- to get it, and a Set- to change it. The Resource would then just be a script, and it might only call those commands and nothing else. So the Resource is very “thin.” But with the functional code as traditional cmdlets, you can test a lot more easily.

But there’s nothing forcing you to name your cmdlets Get, Set, and Test right? Those are the function/method names DSC needs, not hard rules for PowerShell cmdlet names. You should stick to the right verbs, of course, but you can use whichever command verbs are appropriate for the situation.