Installer that use the regsvr32.exe to register a dll

noemig
29th February 2012 04:11 UTC

Installer that use the regsvr32.exe to register a dll
Hello,

I am creating an nsi file to install some dlls but I need also to register them using regsvr32.exe

How can I do this?

Thanks

noemig

MSG
29th February 2012 07:10 UTC

Try doing a google search for 'nsis regsvr32.exe' . If you had tried, you would've found your answer in a matter of seconds.

Afrow UK
29th February 2012 10:22 UTC

Or just use RegDll.

Stu

noemig
29th February 2012 13:37 UTC

thanks
Thank you Stu,

I have found the answer already.

Have a nice day.

noemig

anderci
26th January 2013 19:27 UTC

I have created several VB6 Applications that I make available on my website as 'FreeWare'.
I recently started using NSIS to create install packages. I copy all of the support files into the $INSTDIR , that, for WinVistaAndBeyond, has its own subfolder in the folder structure: C:Users\Public\... This is to reduce the chance that my applications would have minimal effect on and be minimally effected by other applications on the PC.

For each application I have been using RegDLL "$INSTDIR\RICHTX32.OCX" to register each .OCX file used by that application. This seems to work fine when I have installed several of my applications, each in their own $INSTDIR.

The problem arises when I uninstall any of the applications using UnRegDLL "$INSTDIR\RICHTX32.OCX" . This causes all of the applications to have their own copies of the .OCX files to be UnRegistered.

I have not noticed a difference running in a PowerUser Login or 'RunAsAdministrator'.

Anders
27th January 2013 00:14 UTC

http://nsis.sourceforge.net/Docs/AppendixB.html#B.2
allows you to install it shared but then it has to be in a shared location.

Other options:
A) Use reg free COM (XP+, not sure if it works in VB6)
B) Fake reg free COM by calling the Co* functions from VB

PoRtAbLe_StEaLtH
27th January 2013 08:06 UTC

Originally posted by Afrow UK
Or just use RegDll.

Stu

Just becareful under x64bit.

ie. registering shell / unreg shell with RegDLL would leave behind trash in the registry, and leave libraries loaded.

Using `regsvr32.exe` worked correctly.

anderci
4th February 2013 16:40 UTC

Thank you for your responses.

I have been trying to absorb them. I am definitely using VB6 and so far the only error messages from a fresh install of my freeware applications refer to unregistered .OCX files.

My understanding of the terminology in AppendixB faltered with the mention of Libraries. I do want my 'support files' to be NOTSHARED . That is why I copy (File...) them into each application's $INSTDIR . I am trying to continue with this approach to avoid application entanglements.

I do not know what reg free COM is.

I started with regsvr32.exe and am happy to return to it. On some forum I was warned away from it because some PCs may not support it. I do not see a NOTSHARED option with it. e.g.:
ExecWait 'regsvr32.exe "$INSTDIR\RICHTX32.OCX" /S'

Thank you for your help.

Anders
4th February 2013 17:13 UTC

regsvr32 will normally register the file globally (In HKLM) and a shared install is usually not possible.

anderci
4th February 2013 19:06 UTC

Do you mean "a shared install is usually not possible. " or
" a NOTshared install is usually not possible. "

anderci
4th February 2013 19:29 UTC

Is reg free COM also known as 'Visual Studio 6 Installer' ? The website indicates that it, as of 4 July 2012, works with VB6 Pro.

Is it a separate alternative to NSIS ?

Anders
5th February 2013 07:30 UTC

Reg free COM means you don't register the dll/ocx in the registry at all, you put the information in the .exe manifest

anderci
5th February 2013 14:14 UTC

Thank you for your response. It is a relief not to have to go into 'Visual Studio 6 Installer'.

I googled .exe manifest Reg free COM vb6 and was somewhat overwhelmed. I may understand some of it. I think the information in the QueryMgr.vbp file e.g.:

Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.0#0; MSCOMCTL.OCX
Object={38911DA0-E448-11D0-84A3-00DD01104159}#1.2#0; RICHTX32.OCX

ExeName32="QueryMgr.exe"

MajorVer=2
MinorVer=4
RevisionVer=12

must be copied into a QueryMgr.exe.manifest file in XML format to look like:
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
<assemblyIdentity type="win32" name="QueryMgr.exe" version="2.4.12" />
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="MSCOMCTL.OCX" version="2.0" />
<assemblyIdentity type="win32" name="RICHTX32.OCX" version="1.2" />
</dependentAssembly>
</dependency>
</assembly>

And this XML file QueryMgr.exe.manifest incorporated in the NSIS installation into the $INSTDIR with the required support files (MSCOMCTL.OCX, ...)

I saw mention of several tools to create the manifest file, but could not track them down with certainty. The most significant maintenance task, once created, would be the executable application version.

Your guidance is appreciated.

Anders
5th February 2013 17:06 UTC

"<assemblyIdentity type="win32" name="QueryMgr.exe" version="2.4.12" />" I bet the version here does not have to match anything...

anderci
5th February 2013 19:58 UTC

My first try did not work:
E:\Program FiIes\Clark_Anderson\QueryMgr\QueryMgr.exe
(X) E:\Program Files\Clark_Anderson\QueryMgr\QueryMgr.exe
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.
[ OK ]
Here is the content of my QueryMgr.exe.manifest file:
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
<assemblyIdentity type="win32" name="QueryMgr.exe" version="2.04" />
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="MSCOMCTL.OCX" version="2.0" />
<assemblyIdentity type="win32" name="MSCOMCT2.OCX" version="2.0" />
<assemblyIdentity type="win32" name="COMCT332.OCX" version="1.1" />
<assemblyIdentity type="win32" name="RICHTX32.OCX" version="1.2" />
<assemblyIdentity type="win32" name="COMDLG32.OCX" version="1.2" />
</dependentAssembly>
</dependency>
</assembly>

I have tried to attach my Query_Manager.nsi file.
Here is that section:
Section "System Files - WinSysDir"
SectionIn 1 2
SetOutPath "$INSTDIR"
File "C:\WINDOWS\system32\stdole2.tlb"
File "D:\Program Files\Microsoft Office\Office\MSACC9.OLB"
File "C:\Program Files\Common Files\Microsoft Shared\DAO\dao360.dll"
File "D:\Program Files\Microsoft Office\Office\EXCEL9.OLB"
File "d:\Program Files\Microsoft Visual Studio\VB98\VB6EXT.OLB"
File "C:\WINDOWS\system32\msstdfmt.dll"
File "C:\WINDOWS\system32\MSCOMCTL.OCX"
File "C:\WINDOWS\system32\MSCOMCT2.OCX"
File "C:\WINDOWS\system32\RICHTX32.OCX"
File "C:\WINDOWS\system32\COMDLG32.OCX"
File "D:\Program Files\InstallShield\InstallShield Express 2.12\redist\MSVCRT40.DLL"
File "D:\Program Files\InstallShield\InstallShield Express 2.12\redist\COMCAT.DLL"
File "D:\Program Files\InstallShield\InstallShield Express 2.12\redist\RICHED32.DLL"
File "D:\Devlpmnt\LANG\VB6\QueryMgr\QueryMgr.exe.manifest"

; File "C:\WINDOWS\system32\threed32.ocx"
; ;Register RICHTX32.OCX
; ExecWait 'regsvr32.exe "$INSTDIR\RICHTX32.OCX" /S'
; ;Register COMDLG32.OCX
; ExecWait 'regsvr32.exe "$INSTDIR\COMDLG32.OCX" /S'

SectionEnd

I do not know where I have gone wrong.

Anders
5th February 2013 22:12 UTC

There is a tool that will give you more information about manifest errors, "sxstrace" or something like that? I'm sure you can find it if you look on the MSDN blogs...

Edit:
http://blogs.msdn.com/b/junfeng/arch...14/576314.aspx

anderci
6th February 2013 04:43 UTC

SxStrace is not on my developement WinXP PC. After reading over the link you provided, I modified the manifest file:

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
<assemblyIdentity type="win32" name="QueryMgr.exe" version="2.04" />
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="MSCOMCTL.OCX" version="6.1.97.82" />
<assemblyIdentity type="win32" name="MSCOMCT2.OCX" version="6.1.97.82" />

<assemblyIdentity type="win32" name="RICHTX32.OCX" version="6.1.97.82" />
<assemblyIdentity type="win32" name="COMDLG32.OCX" version="6.1.97.82" />
<assemblyIdentity type="win32" name="stdole2.tlb" version="5.1.2600.5512" />
<assemblyIdentity type="win32" name="MSACC9.OLB" version="9.0.0.2719" />
<assemblyIdentity type="win32" name="EXCEL9.OLB" version="9.0.0.2719" />
<assemblyIdentity type="win32" name="VB6EXT.OLB" version="5.0.81.69" />
<assemblyIdentity type="win32" name="Comcat.dll" version="4.71.1441.1" />
<assemblyIdentity type="win32" name="dao360.dll" version="3.60.9512.0" />
<assemblyIdentity type="win32" name="MSVCRT40.DLL" version="4.10.0.6038" />
<assemblyIdentity type="win32" name="Riched32.dll" version="4.0.993.4" />
<assemblyIdentity type="win32" name="MSSTDFMT.DLL" version="6.1.97.82" />
</dependentAssembly>
</dependency>
</assembly>

I listed all of the support files included in the install .nis file. I also used the version numbers displayed by Windows Explorer file properties for each support file.

After installing with the updated manifest on a borrowed WinVista laptop PC, I tried starting the program from its Desktop shortcut. It failed (RICHTX32.OCX not registered).

1) I opened cmd window as Administrator and changed directory to $INSTDIR
2) I attempted to start sxstrace trace -logfile:sxstrace.etl (it displayed usage information?)
3) I ran querymgr from this command line: It worked! querymgr started up and ran
4) I attempted to parse: sxstrace parse -logfile:sxstrace.etl -outfile:sxstrace.txt (it, again, displayed usage information)
5) I successfully started querymgr from its desktop shortcut: Success!

This behavior is puzzling. The sxstrace program seemed not to be working. Usually when a command line program displays usage information, it is because it failed to start. I could find none of the 'log' files.

Anders
6th February 2013 06:55 UTC

I think sxstrace works better on Vista+ but this is not really a NSIS issue, maybe you could ask on the MSDN forums or Stackoverflow?

anderci
11th February 2013 17:48 UTC

Reporting back in:
In the manifest <assemblyIdentity ... version=... /> version accuracy is important!
Also in the manifest, each dependent file must have the
<dependency>
<dependentAssembly>
<assemblyIdentity ... />
</dependentAssembly>
</dependency>
for each dependent file (.dll, ...) All of the examples I saw involved a single dependency.

More later. I still have not had 100% success with at least one WinVista PC.

anderci
17th February 2013 12:32 UTC

Also, a manifest must be provided for each dependency file listed in the primary manifest.

anderci
21st February 2013 15:12 UTC

To Wrap Up:
I finally had success with all 4 Apps in the WinVista PC!

The last program to succeed uses the DTPicker control.

The NSIS script needed to copy both the MSCOMCT2.OCX and MSCAL.OCX from C:\WINDOWS\system32 . I had initially tried copying MSCAL.OCX from D:\Program Files\Microsoft Office\Office: --> That small mistake ~worked by first RunAsAdministrator, then Run as anybody. (The Mysterious Trick I have seen mentioned). Maybe this 'Trick' causes a 'self-registration' of MSCAL.OCX ?

The _.exe.manifest needed MSCAL.OCX as well as MSCOMCT2.OCX...

I also added the MS Windows Calendar... to the components for my Application.

I have not found any clear 'requirement' for MSCAL.OCX. Mysterious?

Thank you for your help!