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
I have a legacy piece of software that I am supporting that needs to register some OCX controls and DLL files. When using the windows::regsvr32 class some of my controls are registered on every puppet agent run.
I have had a bit of a look at the code and can see the powershell that is being used in the erb template for finding the CLSID entries in the registry. It would seem what is defined there isn't broad enough to find some controls that are registered with the regsrvr32 utility as it would seem that it isn't always consistent on where it puts it.
In my searching through the registry I found the CLSID in different spots for different controls.
So I have tested a bit of powershell that searches the registry for the CLSID from that path and returns exit 1 if it doesn't find a match and it works ok but of course takes a bit longer than a direct Test-Path.
I'm happy to make a pull request if you like to edit the erb template to run my updated powershell that does a broader search but thought I would raise this issue here first as it would have some performance impact.
The text was updated successfully, but these errors were encountered:
I have a legacy piece of software that I am supporting that needs to register some OCX controls and DLL files. When using the windows::regsvr32 class some of my controls are registered on every puppet agent run.
I have had a bit of a look at the code and can see the powershell that is being used in the erb template for finding the CLSID entries in the registry. It would seem what is defined there isn't broad enough to find some controls that are registered with the regsrvr32 utility as it would seem that it isn't always consistent on where it puts it.
In my searching through the registry I found the CLSID in different spots for different controls.
msvbvm50.dll -- runs every time
TeeChart.ocx -- only runs the first time -- unless statement correctly detects it
TSGACAL.OCX -- runs every time
COMCTL32 -- only runs the first time -- unless statement correctly detects it
The only common element in those is:
HKLM:\SOFTWARE\Classes\*
So I have tested a bit of powershell that searches the registry for the CLSID from that path and returns
exit 1
if it doesn't find a match and it works ok but of course takes a bit longer than a direct Test-Path.I'm happy to make a pull request if you like to edit the erb template to run my updated powershell that does a broader search but thought I would raise this issue here first as it would have some performance impact.
The text was updated successfully, but these errors were encountered: