The main disadvantage of class-based DSC resources is that you cannot use them in an environment that has both PowerShell V4 and PowerShell V5 installed, while module-based DSC resources work fine in either version. This makes transitioning hard as it is unlikely you will be able to upgrade an entire environment to PowerShell V5 at once. This will influence your decisions on making custom DSC resources now, as you will have to anticipate and plan for the version of PowerShell that is on the target host in the future.

This is especially important if you are making a DSC resource you want to share with the community. If you choose to implement it as a class-based DSC resource, then you are potentially limiting the number of people who can use your resource until WMF 5 becomes the most commonly installed version.

Miscellaneous minor problems with using class-based DSC resources are shown in the following list:

• The types that you create in a class are not available outside the module yet. This means that, if you have several common variables, enums, or methods, you have to create them in each class you make. There isn't a global way to address them outside the module they live in.
• You cannot have class-based and MOF-based DSC resources inside the same DSC resource module.
• You cannot unload classes from a running PowerShell session using Remove-Module, which can cause a failure to reload a class-based DSC resource when the LCM is set to the ForceModuleImport debug mode.