After a bit of a false start the WMF 5.0 installer package has been republished. This released fixes the PSModulePath issue that popped up on the first release of this package.
The changes to this package are:
Changes in the republished packages The KB numbers of these packages (KB3134758, KB3134759, and KB3134760) are different than previously released WMF 5.0 RTM packages (KB3094174, KB3094175, and KB3094176). These packages have fixes only for the PSModulePath issue compared to the previously released WMF 5.
Introduction Recently I had a need to have an application published in Chocolatey. If you’re not familiar with Chocolatey, it is:
a Machine Package Manager, somewhat like apt-get, but built with Windows in mind.
The application I needed to package was actually a Microsoft tool called DevCon.exe and is available freely from Microsoft as part of the Windows Driver Kit (WDK). The WDK is a massive 2.5GB download, and I needed this one tiny (80kb) executable to be automatically installed and used as part of some Integration tests for another project using AppVeyor CI.
The purpose of this series of articles is to try and document a few of the lessons I learned while releasing new DSC resources as well as contributing to the existing Microsoft Community DSC resources. These articles are not intended to tell you how to write DSC resources from a programming perspective, but to give you some ideas on what might be expected of a DSC resource you’re releasing to the public.
I’ve been spending a bit of time lately completing a set of DSC Resources for configuring iSCSI Targets and iSCSI Initiators. One thing I’ve noticed is that these iSCSI cmdlets are extremely slow:
21 seconds is just too slow!
Now, if I was just calling this cmdlet every now and then it really wouldn’t matter so much - as long as it works. However, because this cmdlet is going to be called every few minutes when used in a DSC Resource it is unacceptable.
