Software Deployment

Can you register it manually using regsvr32?
Check for dependencies using Dependency Walker

ORIGINAL: aXz
I did some searche on the web and found this:
3) Your file cannot be registered using an API call and you must use RegSvr32.exe, and LOL...I'd *love* to know where you found THAT gem.

Ohh.... I have som general problem with this I think. I tried to press Ignore just to see if my very first Custom Action that will install a Patch to the installation would work. And there was 110 more files that get the same error message [&:]

I read someware before I start the Setup Capture that I should not use the SmartMonitor during the setup capture for this software?
Can that have something to do with it? Im just speculate now....

First please try to register the DLL manually by open cmd.exe and run regsvr32 <path to .DLL>.
If it doesn't work due to dependencies not installed then use Depends to find out the missing DLL dependencies.

And finally could you make sure the default setting is to not self-register COM components, then re-capture the legacy setup and post your result meaning if you got the same issue or not.

Which version of WPS are you using?

I did the regsvr32. I got a messagescreen that says that the .dll file was successfully registrated. But when I press the retry button I cant get forward in the installation without press the ignore button.

I am using WPS 7 Pro.
I will try to do a new snapshot. Should I use the SmartMonitor or not during the setup capture?
And where do I set the option to NOT self-register COM components?

EDIT: I think I found it. The "Enable ordering of self-registration (SmartMonitor only) is NOT checked.

Self-registration in MSIs is the work of The Devil. DON'T do it!

- make a note of all the DLLs in the SelfReg table
- use WiseComCapture to create .REG files for these DLLs. Remember that WiseComCapture *ONLY* checks for the DLLRegisterServer entry-point when deciding if a file contains COM information: they don't always. If you end up with a .REG of less than 100 bytes, you can assume that the DLL in question is one such.
- import the .REGs into your project, answering 'Yes' when Wise asks you if you want to use the advertising tables.
- compile and test

When complete:

- run your MSI
- start a lighweight snapshotting tool (I use Ziff-Davis' In Control) and take a 'Before' snapshot
- now re-run the vendor install OVER THE TOP of your install
- use the snapshot tool to take an 'After' snapshot
- check the resulting output to check that the vendor's install hasn't replaced/deleted/added *relevant* files or registry entries.

No.
First open the template your are going to use using Windows Installer Editor. Then you should find the checkbox in the Advertising tab from the Tools menu -> Option. Uncheck the checkbox! Save the template, do NOT compile it.

I normally use SetupCapture and skip using SmartMonitor as it adds more garbage to the package which saves me time during cleaning-stage.
Then make sure to use advertising instead of registry as-is during capture configuration, sorry can't remember the exact name from memory.

WiseComCapture ORIGINAL: VBScab

- make a note of all the DLLs in the SelfReg table
- use WiseComCapture to create .REG files for these DLLs. Remember that WiseComCapture *ONLY* checks for the DLLRegisterServer entry-point when deciding if a file contains COM information: they don't always. If you end up with a .REG of less than 100 bytes, you can assume that the DLL in question is one such.



My SelfReg table is empty. Is that good or bad?[:)]
And when I look on the left side menu in the installer editor I cant see any WiseComCapture??

When the installation stops and I get the first 1911 Error message I cancel the install and go to cmd---> Type regsvr32 "Path to my share point where the dll is located". The result is that the .dll file is successfully registrated.
My belief now is that next time I run the install it will not complane on that .dll anymore. And that the installation will stop on the next .dll file that has to be registrated. But it stops on the same .dll file (V3DTree.dll in this case)

Humm... I look around in Dependency Walker. I have never use it before but I think I have found something and maby one of you can say if I have found something worth dig in to?
When I in Dependency Walker choose to see the hole path there is only two .dll's that have the path to the Wise Sharepoint. The rest of the .dll's are located under C:\Windows\System32\
One of the files located in the Wise Sharepoint is the V3DTree.dll that I manage to successfully registrate.
File number two is called EAICOMCREATE.dll and when I try to registrate it, it dosent work.
So can EAICOMCREATE.dll be the problem here?

EDIT: Wrong of me there is actually 4 .dll files that is located in the Wise share point. (MSJAVA.dll, DBGHELP.dll, EAICOMCREATE.dll and V3DTREE.dll) The rest are located in the System32 folder and one file are located in the C:\windows\winsxs\x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.0.2600.2180_x-ww_522f9f82\ folder (GDIPLUS.dll)

Why cant I found WiseCOMCapture.exe?
I have searched in my Altiris folder on my develop computer.
I have even gone via Start--> Search and Searched my whole C: for the word WiseCOMCapture
Nothing is found. I would really want this SAP package to work in the end of next week so it would be greate if somone now why I dont find it ?

EDIT: I found it! It was on the server...

I have done one .reg file for on of my DLL's now.
Is it ok to import the .reg file under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Current Version\Shared Dlls\ ??

No.
That is added by Windows Installer when the msidbComponentAttributesSharedDllRefCount attribute bit is set for the component holding ex. a file located in the System32 (SystemFolder) folder.

Only ONE DLL?!?!? I think, from memory, there are over 100 registerable files in a full SAP installation. Applications like this are one reason why I wrote scripts to search for such files and run WiseComCapture against them. I have another which concatenates the .REGs into one, to make importing them a one-step process, as WPS has the happy knack of forgetting the source folder for them, always reverting to its 'Projects' folder. (Let me think...When did I request a feature to fix that? 2005, was it?)

Once you have your .REGs, select the 'Registry' view in 'Installation Expert', right-click somewhere in the bottom left-hand pane and select 'Import from .REG'. If you have it set up correctly, WPS will ask you if you want to use the advertising tables. Select 'Yes'.

PS.
Before you ask, I'm no longer sending my scripts out to people. They started to turn up on sites all over the place, sometimes hacked about such that they didn't work - and with my name on! - or with my name removed.

Hi,

Ok... You can say what you want now but I took the .dll files one by one [&:]
Anyway its done now and I will have to import them in my package.
I imported the first .reg file and did a test install once more. It seems to work because I dont get the error message regarding that specified .dll file I imported. The installation stops at the next .dll insted.

Of course there are som questions.
1: Alot of the files are only 1kb and dose only contain this:
"Windows Registry Editor Version 5.00"
I guess that I dont need to import this files?

2: Can I take the information from all .reg files and put in one file? So I dont have to do the import procedure 100 times?

3: One of the files the installation complane about is saplogon.exe. For me that sound really stange. You cant registrate a .exe file??

1. In response #7, I said that any file under 100 bytes means that the DLL in question had the DLLRegisterServer entry-point but didn't contain any COM information. I wish to revise that assertion, following a recollection I had last night. Try re-doing those DLLs but with your command prompt open AT THE DLL'S INSTALLED PATH, and calling WiseComCapture using its full path. Of course, if that path is %SystemRoot%\System32, you can figure that the assertion holds. The reason is that WiseComCapture *sometimes* creates the .REG instead of erroring if the DLL has dependencies which it can't find.

2. Of course. You will find it VERY useful to create yourself a script to do that: importing more than about half a dozen will drive you nuts and, when you've done it as often as I have, you'll bless the day you built a script to take the chore out of concatenating files manually. That, after all, is why we use these stupid machines - to make our lives simpler.

3. Most EXEs which register themselves use the switch /RegServer. Occasionally, developers take it upon themselves to change it to /Register. Run the EXE and add that switch. If no UI or error message appears, it's a valid switch. You can sometimes load the EXE into a text editor and search for the switch text, too (without the '/', obviously).

As an aside, you could have found out that the EXe required registration by following my packaging practise, also detailed in response #7. Any registry entry against a key 'HKCR\[CLSID]\LocalServer32' indicates an EXE which registers itself.