CODEWITHSUNDEEP
vb6
w0051977
w0051977

Reputation: 15787

How to install OCX components of an application?

I have copied some components on an App server so that I can run a VB6 application

TABCTL32.OCX
TABCTL32.DEP
MSWINSCK.DEP
MSWINSCK.OCX
MSMAPI32.DEP
MSMAPI32.OCX
FTP.OCA
FTP.OCX
COMDLG32.OCX

I took some advice from the answer of another question on here. Can anyone advise if it is safe to do this. There is an ASP.NET application (framework version 3.5) installed on this server as well.

Upvotes: 1

Views: 2900

Answers (2)

wqw
wqw

Reputation: 11991

If you really want to achieve side-by-side deployment of these OCXs (and DLLs) without resorting to VB6 auto-registration hack, best would be to use an application manifest for registration-free COM.

We are using UMMM to create these automatically at build time, in your case manifest creation will be a one-time job.

Here is how to use UMMM in your case. First create an App.ini file like this

Identity App.exe YourCompany.App "Application 1.0"
File TABCTL32.OCX
File MSWINSCK.OCX
File MSMAPI32.OCX
File FTP.OCX
File COMDLG32.OCX
# more OCXs/DLLs here...

"Compile" manifest with UMMM.exe like this

c:>UMMM.exe App.ini App.exe.manifest

Either place App.exe.manifest next to your App.exe or embed it as a resource with mt.exe from Windows SDK like this

c:>mt.exe -nologo -manifest App.exe.manifest -outputresource:App.exe;1

Unregister OCXs/DLLs (this is important) and test you application.

Upvotes: 2

David W
David W

Reputation: 10184

Files ending with an ".OCX" extension are actually 32-bit in-process COM DLL's that must be registered in order for them to be used. This is accomplished via the command-line "regsvr32" utility.

Copying these files to the application's host directory will not be adequate to allow the application relying on the components provided in the .OCX files to access them. This is because applications will create instances of COM objects via their registered programmatic ID ("ProgID"), that Windows will, in turn, translate to the CLSID and COM in-process server DLL that provides the implementation for the object(s). If the OCX isn't registered, there's no COM information to allow Windows to perform the required mapping.

The ProgID's, ClsID's, and related type library informatoin are "published" to Windows via the RegSvr32 utility, which really just loads the target DLL/OCX and specifically calls the COM DLL entry point "DllRegisterServer," which allows the DLL to publish its COM registration information. If this is not done, no COM registration is available, and calls for the objects hosted in the OCX/DLL will fail.

The absence of the vital COM registration information is the reason copying OCX files to the host folder is not sufficient for the consuming application to leverage the COM objects hosted therein.

Additional information re file extensions

  • .OCX - In reality, it's just a COM DLL with a different extension. These names were given as containers for VB extensions under the old "*O*LE *C*ontrol E*x*tension" moniker, hence OCX.
  • .DEP - Windows Dependency files. These files, which tend to have a Visual Basic "Setup application" heritage, typically contain information about the dependencies a given EXE or DLL has on other DLL's. For example, A.EXE may depend on B.DLL, but B.DLL may also depend upon C.DLL.
  • .OCA - OCX type library cache. This is typically constructed on the fly, and is rebuilt when needed.

Upvotes: 4

Related Questions