building some resources./modules in DSC. Run into a bug, make a fix then try again. What I’ve noticed is that if you modify a resource after it’s been dropped into the modules directory and effectively “live”, Windows will continue to use what’s in memory. Running a get-module and it’s kin seem to all work in the current session … so how do I force Windows to re-read it’s modules folder and try the new module without going as far as a reboot?
As an extension to this question: updating via a pull server.
As it stands I understand I need to bump up the version number on the zip filename and manifest to make sure clients know to download a newer version … but should I also update the GUID or does that stay consistent? Documentation seems unclear here.
On a pull server, you only need to update the version, but you do have to generate a new checksum. The checksum is how clients now there’s a new download.
There shouldn’t be anything “in memory,” though, at least not after the DSC scheduled task finishes running. It doesn’t run as a background service, so once the task finishes, there shouldn’t be a process for any memory to be associated with. Now, if you’re just testing live in a console - then yes, once a module is loaded, it has to be explicitly removed before PowerShell will re-load it. That applies to resources as well. But, worst case, closing that shell session will dump its memory. A new session would have to load the module again.
So I guess maybe some more detail on how you’re testing and running the modules?
You need to both update the version of the module that contains the resource, and you need to recompile the MOF. (MOF configuration documents contain a reference to the resource module version.)
Ahh dave … recompiling the MOF probably explains the pull weirdness I saw. Thank you!
As for the “in memory”, Ill retest and make sure I’m summarizing the problem correctly, but it was a matter of something similar to:
Added a module and applied a mof to a machine as a means of testing.
Discovered some random error (forgot about an environment I needed to account for, for example), so I update the resource directly in the modules dir with ISE.
Force the scheduled task to run in order to retest the module and realise the “old resource” is still getting processed. At this point I’ve not changed any version numbers as I’m just testing.
I don’t remember if i did something as simple as close/reopen the PS session, but as this was a module I assume running in the system space … I didn’t think that would have an impact.
There’s some caching that happens in DSC; by bumping the version numbers, you force it to invalidate the cache for that particular module and load it again. In the original version of PowerShell 4.0, the only way to get around this was to kill the wmiprvse process that was hosting the Local Configuration Manager.
In the latest patches for WMF 4.0, and in the WMF 5.0 preview, you can instead set “Debug Mode” in the LCM, which disables caching and will cause your changes to take effect right away. This is mainly useful for developer workstations.