Software Deployment

Almost without question, the OCX depends on another DLL and it is the absence of the dependency which is causing the failure. This is the single-most important reason why you should NOT use SelfReg, RegSRv32 or MSIEXEC /Y - if there's a dependency and that dependency is missing, registration will fail.

Load the OCX into the (free) Microsoft tool Dependency Walker. That will show the list of all files which it depends upon.

When you've isolated and handled that (who you handle it if it's missing is up to you), use WiseComCapture to create a .REG for the OCX. Import the .REG into your project and, when prompted, select to use the advertising tables rather than the registry. That assumes that you have WPS set up correctly to NOT use self-registration but to use those advertising tables.

Hi VBScab and thanks for you replying.

I've tried everything you mentioned and not sure what I am doing wrong. If I follow your step correctly this is what I've done.

First I downloaded Dependency Walker and viewed the two DLL's that will not register and found a DLL it was Dependant on. Which was "dwmapi.dll". At least it showed it could not be found. But there was a couple of more in "Red" that i did not understand what to do. Example Snapshop Below.

DCUBE3.OCX
http://picasaweb.google.com/lh/photo/4K6Y0kokKzwW8bP8_a6o4A?feat=directlink
OLCH2X7.DLL
http://picasaweb.google.com/lh/photo/HeLP380yAQ32eTPKX9FDag?feat=directlink

As you can see, DCUBE3 I believe is missing one DLL. dwmapi.dll, I'm not sure about the others in Red. I downloaded dwmapi.dll and dropped it in c:\windows\system

Next I've done the following.

1.Removed the dcube3.ocx and OLCH2X7.ocx files from row of the "SelfReg" Table.
2.Created a blank reg file and then ran the WiseComCapture in the Altris directory. Example: WiseComCapture.exe /r {full path of dll or OCX} {full path of add.reg}. It seemed to capture those reg setting into this file.
3. I imported these reg settings in Wise Studio.


I ran the test installation and it managed to finish installing BUT when I launched the application, it kicks off a repair. I'm not sure what it was doing in the repair. So I used "InstallWatch" and managed to capture a bunch of cached files. But there were also a lot of HKCR keys that were created.

At this point, I'm not sure how to get rid of the msi repair when it kicks off.

Any suggestions?

The entries in red are dynamically-loaded. You'll see MPR.DLL in DW a lot.The entries with the yellow question mark are the ones to be concerned about, since they're simply missing.

The repair is probably completely unrelated. Check out the Event log: it will highlight the component ID of the component which is triggering the repair. Work backwards from there.

maybe see what the app does without wisecomcapture.exe - used it once per Ian's advice, didn't work, don't recall how I resolved it but selfreg really shouldn't be necessary any more.

http://www.datadynamics.com/forums/76358/ShowPost.aspx

this is a very old posting but it looks like there was a known problem with this ocx.

It's a long shot but is yours this old version?

Hello everyone,

I decided to go back and install the vendors application. After it was completed, I verified the two files were in the %SYS32%. I decided to try and run "regsvr32' to see if that OCX file would register. I found out that the same error occurred with registering those OCX files.

In other words, the vendor was installing these files and was probably not even working to begin with. So, now I'm just trying to figure out what is launching the repair on first run.

I also found out that if you can go to the Component in Wise and right click the object (file) and click "rescan advertising", it basically does the same thing the WiseComCapture does and add those reg keys in the WSI.


So, at the moment, I can get the installation to install successfully without rolling back with the 1904 Error. But upon first launch, I see a repair kicking off on a per user basis. Which means there must be HKCU keys being recreated.

I used InstallWatch and seen 0 keys being modified or added in the HKCU, I also checked the event viewer and see no entries for the repair kicking off.

Although I did this before I left work yesterday, I'll give it a second try this morning. I get back to everyone with an update and hope I have better luck this morning.

I also checked the event viewer and see no entries for the repair kicking off.You therefore have what must be a unique set-up. I've not known a repair to NOT be recorded in the Event log. Which log are you looking in?

You correct, the reason is was not recorded because I noticed that the WMI on my machine is using the %SystemRoot%\system32\msimsg.dll located at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Application\MsiInstaller. I guess there is a known problem with the event viewer recording a bunch of NULL Values.

Example:
Event Type: Information
Event Source: MsiInstaller
Event Category: None
Event ID: 1042
Date: 1/27/2010
Time: 9:53:01 AM
User: NT AUTHORITY\SYSTEM
Computer: VMCORE0N
Description:
The description for Event ID ( 1042 ) in Source ( MsiInstaller ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: {C1F1086D-1E43-401B-8819-632FA4FDC998}, 3068, (NULL), (NULL), (NULL)


After changing the value in the Registry to point to %SystemRoot%\system32\msi.dll, now I no longer have null values to read in the Event Viewer and found the problem key that was missing. So I imported the reg key into the WSI and recompiled and after testing it worked just fine. Case Closed. :)

Thank you for all your input everyone, special kudos to VBScab.

:)