Image of Navigational Map linked to Home / Contents / Search Registering Remote Components

by Ross Mack - GUI Computing
Image of Line Break

On a recent project my team was struck by an annoying malady. We had a number of server-side components that our application used, yet in some cases they were being instantiated locally. This tended to create performance bottlenecks that didn't really exist and leave us chasing different versions around different PCs that had bugs that had been fixed in newer versions.

The problem arose from the fact that we had installed and registered the files on each machine to provide the registry information we needed to be able to resolve the classname into a GUID and then request that object from the remote server. For more information on this process see Jim Karabatsos's article on Creating Remote Objects.

The solution seemed to be to find some way to register the files on each PC without them staying there. I reviewed my potential options over a few pints and came up with a brilliant idea. In the morning I had completely forgotten what that was so I started investigating. I knew that the VB setup wizard could register components for remote use without actually installing them so I decded to have a look into that first.

Working backwards from the Setup Wizard documentation I discovered that it uses some files created by VB at compile time to generate the information for the client computers. This rather enigmatic little file is called a .VBR file. And here is the story of how you make one...

Finding the Option

When you are about to compile your remote component you need to go into the project properties dialog box (pictured) and to the Component tab. Here you will find a frame titled 'Remote Server' within it is the mystical 'Remote Server Files' checkbox. To be honest this checkbox could perhaps be better entitled something like 'Generate VBR and TLB files on compile'. But it is not.

Once you have turned that checkbox on and compiled the component you will find in the same directory as the resultant DLL or EXE two files. They will have the same base name as your component but a VBR and TLB extension. So you will end up with a few files, some of which will be along the lines of:
MyObject.DLL
MyObject.VBR
MyObject.TLB
and so on.

These files are the key to registering your component for remote use only. The other thing you need in a file called clireg32.exe. You should find this in your VB5 or VB6 install somewhere. With the setup kit for VB5 and somewhere competely different, in amongst the common files for VB6. The path usually is:

c:\program files\Microsoft visual studio\common\tools\clireg\clireg32.exe

This exe takes a number of parameters to get it to work. Here is a sample command line. We will assume that clireg32 is in the current directory (or is in the path) and that the VBR and TLB files are in the current directory.

CLIREG32 MyServer.VBR -s MyServer -d

This will install the remote component registry information for the component detailed in MyObject.VBR (presumably MyServer.DLL or MyServer.EXE), it specifies that the remote server to create the object on is 'MyServer' (the -s parameter) and that DCOM should be used rather than remote automation (the -d parameter).

There you are, that's all there is to it. You can always create the object on an alternate server using VB6's CreateObject function with the optional servername argument (or by checking the code in Jim Karabatsos's article, if you are using VB5), you do not have to stick with the server specified on the clireg commandline (although it does seem to require this parameter).

There is also a -u parameter that you can use to deinstall the information for a specified VBR file.

Using WISE

You can easily integrate the registration of remote components into a WISE script also. You simply install clireg32.exe and all your VBR and TLB files into a temporary location. WISE provides the %TEMP% variable to identify just such a location. You can then use the 'Execute Program' script item to execute CLIREG32 passing the appropriate parameters. Make sure you check the 'Wait for program to exit' checkbox so that WISE waits for CLIREG2 to finish it's work before going on to the next script item.

You can then have your WISE script delete CLIREG32.EXE, the VBR and TLB files. Neat and clean! In this case you will also want to include on the CLIREG32 command line two additional parameters, -nologo and -s to prevent the display the introductory message box and to do a silent install.

Using a Batch File

For my current development environment I use a simple batch file (yes, a batch file) to update our NT machines with components. Unfortunately the batch file requires command prompt extension that are still only available under NT, but it's certainly handy there.

If you like you can change the extension to .cmd and call it a command file, NT will understand.

The batch file simply updates any DLL, OCX or VBR files on the client PC that it finds in it's own directory. It's actually quite well behaved and will attampt to unregister previous versions if they exists and so on. I simply run this batch file as required or place a shortcut to it in my startup group, the batch file itself sits on a server where people who are updating the components can simply place the updates with the batch file, that's all they need to do.

@echo off
rem -- Check a system variable to see what OS we are, always set for NT
if not "%OS%"=="Windows_NT" goto notnt

rem -- Did we get a parameter - are we calling ourself ?
if not "%1"=="" goto singlefile

rem -- Run clireg for all the VBR files in this directory
for %%f in (*.vbr) do clireg32 %%f -s MyServer -d -q -nologo

rem -- for all the OCX and DLL files in this directory call 
rem -- this batch file passing that file as a parameter
for %%f in (*.dll *.ocx) do call %0 %%f

rem -- We have processed all files in this directory that we want to
goto end

:singlefile
rem -- If the file already in sys32 directory unregister it
if exist %windir%\system32\%1 regsvr32 %windir%\system32\%1 /u /s

rem -- if the file exists in sys32 use replace to update it
if exist %windir%\system32\%1 replace %1 %windir%\system32 /u
rem -- if the file still not in sys32 use replace to put it there (could use copy)
if not exist %windir%\system32\%1 replace %1 %windir%\system32 /a
rem -- register the file /silently
regsvr32 %windir%\system32\%1 /s
goto end

:notnt
echo This is simply not NT ! This batch file only works under NT.
echo Sorry.
goto end

:end



Written by: Ross Mack
October '98

Image of Arrow linked to Previous Article Image of Arrow linked to Next Article
Image of Line Break
[HOME] [TABLE OF CONTENTS] [SEARCH]