You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This invokation of Import-Module in New-ClassResourceObject seems to re-import the module of the class resource on each invokation even if it has already been loaded. It seems to happen once per bound resource, so the bigger the configuration document the slower the creation of the instructions. Some resource modules are large enough that they take seconds to load. The modules should probably remain cached as they are imported, but they don't currently seem to be.
The text was updated successfully, but these errors were encountered:
It looks like this call to Test-MofResourceType can inadvertently invoke Remove-Module each time a new bound resource is created. The apparent offending call site seems to use an unreliable method for detecting whether a module is already loaded. Here is a trace demonstrating the problem from that call site:
The file extensions differ differ so the module described by $DscResourceInfo unloads the module. That is incorrect. A more rigorous method of detecting whether a module corresponding to a DSC resource is loaded should be used.
alx9r
changed the title
Resource Importing Should Be Cached
Test-MofResourceType Inadvertently Unloads Module
Dec 26, 2016
This invokation of
Import-Module
inNew-ClassResourceObject
seems to re-import the module of the class resource on each invokation even if it has already been loaded. It seems to happen once per bound resource, so the bigger the configuration document the slower the creation of the instructions. Some resource modules are large enough that they take seconds to load. The modules should probably remain cached as they are imported, but they don't currently seem to be.The text was updated successfully, but these errors were encountered: