Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

DCOM registration 1

Status
Not open for further replies.

grad

Programmer
Apr 13, 2000
15
US
I am new to using DCOM. I am developing using VB6.0&nbsp;&nbsp;How do I remotely register a DCOM component without creating an installation &quot;package&quot; or using the install builder (this seems a bit too much)<br><br>I placed the DLL on the server and did a regsvr32 and on the client I left the VBR and the TLB files and ran CLIREG32 with all the parameters.&nbsp;&nbsp;<br><br>WHen I made a reference to the TLB in my VB project it did not give any errors but on the createobject call in my client machine code it gave me an error trying to create the object.<br><br>Has anyone else registered DCOM objects without creating a complete installation diskette or package?<br><br>thanks<br>mark
 
hi grad,<br><br>steps for DCOM.<br>1. Register your dll on the server by running regsvr32 xxx.dll<br><br>2. You need a surrogate exe on the server in which your dll is supposed to run. If you use MTS then it's quite easy. Open MTS explorer create a new package and put your component in that package.To confirm that it has been configured to run under MTS open the registry and look for the progid of the component. Using that get the clsid and look under it for localserver. you will find it to be mtx.exe <br><br>3. Register on the client side.<br><br>4. Now there are 2 options<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;a. run dcomcnfg on client. select your component and then under that select the computer that you want your component to run on as the server. in the vb code call createobject(&quot;progid&quot;)<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;b. in vb code call createobject(&quot;progid&quot;,&quot;servername&quot;)<br><br><br><br><br>
 
How do I register the DLL on the client machine?&nbsp;&nbsp;Do I run the clireg32 as I did with the VBR and TLB files or is there another easier way&gt;<br><br><br>mark
 
You just use it on client machine. If it correctly registered on the server, it creates the object and uses it. <p> <br><a href=mailto: > </a><br><a href= > </a><br>
 
hi grad,<br><br>This is thycattusserry again. just changed my name to juliaroberts. ardent fan of hers!. anyway back to the topic...<br><br><br><br>Registering on the client side.....<br><br><br>1. copy the VBR file to the client. If you want to make a reference to the component then copy the tlb file also.<br><br><br>2. run clireg32 xxx.vbr , select the option as DCOM and give the remote server ip address.<br><br>3. bingo! everything will work<br><br>bye.<br><br>hi dannyb,<br><br>what do you mean by &quot;you just use it on client machine&quot; ?<br>just copying the VBR and tlb files to the client won't work. you need to register the vbr file with clireg32. Or is there something that I am missing? please correct me if I am wrong<br><br>bye<br><br>&nbsp;
 
I have create an Activex dll and registered it on a server.&nbsp;&nbsp;I took the remote files VBR and TLB and placed them on the client in the winnt\system32 directory and ran clireg32 xx.vbr<br><br>I then created a client app and pointed the reference setting to the xxx.tlb file on the client.&nbsp;&nbsp;WHen I run the app the createobject call results in :&quot;Runtime error 429.&nbsp;&nbsp;Cannot create object&quot;<br><br>Am I missing a step.&nbsp;&nbsp;I ran the dcomcnfg on the server machine and set all the proper permissions.<br><br>Has anyone been successful in registering and running DCOM components?<br><br>thanks
 
Hi All, sorry about what I said, (You just use it on client machine. If it correctly registered on the server, it creates the object and uses it. ), that only applies to an EctiveX EXE not a dll, which is the point of this discussion.<br><br>I think that error 429, occurs when you can't access the registry. Anyway, to run a dll on a remote machine you have to use MTS. Otherwise change the dll to an activeX exe, and configure the security part with dcomcnfg. By definition a dll runs in-processes with the thread that created it, impossible to do where the tread is on another machine.<br><br> <p> <br><a href=mailto: > </a><br><a href= > </a><br>
 
hi grad!<br><br>Yes , I have been quite successful in registering and running DCOM components created in Visual Basic as well as ATL COM (VC).<br><br>If you have created an Active X dll then follow these steps:-<br><br>1. Register the dll on the server machine using regsvr32 xxx.dll<br><br>2. Open MTS explorer. Create a new package. Add your dll as a new component into the package that you just created.<br><br>3. Copy the VBR and TLB files to the client machine. <br><br>4. Run clireg32 xxx.vbr on your client machine. This will ask you for the IP address of the server. Fill in this detail.<br><br>5. Now you have 2 options for creating the object.<br><br>    a. Call CreateObject("progid of the component")<br>or<br>    b. Set a reference to the tlb file in your Vb project and create the component using the 'new' key word.<br><br>This is sure to work. I just tried it out to confirm it.
 
On my application, I have one machine that will be called by many users (machines) that will access this application.&nbsp;&nbsp;I get a threading error and DCOM unregistered. You mention client machine and server machine in your instructions, however, like I said, on my machine where MTS is, many other machines will be calling this application ie. 200 or more, does that make these machines the client machines and those machines all have to run clireg32xxx.vbr and copy VBR and TLB files on them as well? I have 2 .dlls, one in VB, the other handling threads and calls to the database in C++.<br><br>Any help is greatly appreciated. Thanks.
 
<br><br>hi!<br><br>Server machine:--&nbsp;&nbsp;the machine one which your dll's are going to run<br><br>Client machines:- the machine on which your client apps (those apps that access the dlls on the server) run.<br><br>So as per the above definitions your machine running MTS with those dlls becomes the server and the other 300 becomes client machines<br><br>You need to register your dll on one machine i.e is the server machine.&nbsp;&nbsp;<br><br>If your dll was written in vb then you need to copy the .vbr and .tlb files to each client machine and regsiter them there using clireg32.<br><br>If your dll is written in ATL (vc++) then the process is different. please let me know if this is the case.<br><br>note:-whatever dll you plan to put under MTS should be a COM component.!<br><br><br><br>
 
<br>Rather than copying the VBR and TLB files to the client machines and manually registering them, can we just export the MTS package which would create a setup program that we can run on the client machine which would take care of the client registeration process?
 
Hi<br>Use the package and deployment Wizard available in VB to make a client setup program. Copy the setup files onto the client and run the setup.exe<br><br>
 
Hi everyone.
I am sort of having the same dificulties.
I want to develop an application that has a front end presentation layer on the client machine, that call several functionality gathered as a com dll (or exe or both)...
Since this dll will be changing from time to time and new ones will be added I want a dinamic way of callying these
dll function in a smooth way, and transparent to the user.
I require a system where I do not necessary need to login in
but at the same time, a security functionality is a must (you figure it out). Since It is a system to be working over the internet, The server will be in fact an IP address and not I server name...
If you can help me to achieve this I will compensate financially....

Thanks

PS pauloSousa@hotmail.com

 
maybe i missed a whole chunk from this splendid thread - but -
we're running NT clients and servers and the server/client app work fine on the same pc.
all the DCOM settings are set to allow everyone full access to anything possible (obviously only a tempory measure).
when client is installed on new pc - error is 429 ActiveX object cant be created etc.
WHY?
a couple of things to note may be that
i) the server object was created in NetExpress (linked to COBOL backend) and on packaging doesn't provide a .tlb or .vbr? - it does, however, provide a client .reg file that appears to pass information into the client registry regarding the location of the server object
ii) we were informed that we may have to run a Remote Registry Service (to allow the client access to the server machine's registry) but the only details we can find for this are in relation to windows95 (including on the MS site)?

any advice would be most appreciated !
cheers
m
Mark Saunders
:)
 
im still confused about when you use createobject(progid, servername). What does this give you that createobject(progid) doesnt? does it take the place of have to configure the address of the server when the client is installed? and if so.. which takes precedence?
 
I have an active X exe in VC++ ( ATL) . I need to remote this what do i do??? please help me URGENT>>>>>>

mail me at binith.t@svw.com
 
Hi folks,

I'm trying to learn how to create a DCOM component in VB6.
I've read the thread and found some answers to what I need, however, the following still remains unanswered:

1. I read in several on-line DCOM tutorials that DCOM components, if to be run on a remote server, must be compiled as an exe and not as a dll. This is because they run out-of-process in a separate address space. dll's on the other hand run in-process and in the same address space as the calling program. In this thread, so far, everyone is talking about registering dll's on the server and not about exe's. Could someone please clarify this for me? Am I missing something?

2. There's mention of the use of MTS to run the dll on the server side. My question is: What if one doesn't use MTS? I'd like to register a DCOM exe on a remote server. Is this just a matter of running regsvr32 xxx.exe? Could someone please explain how to achieve this?

3. Since development will be done in VB, I understand that some extra files will be generated for use on the client side, namely the vbr and tlb files. I also understand that these files will have to registered on each client using clireg32 xxx.vbr. Does this mean that only the vbr files are to be registered on the server and not the tlb?

4. In the client application, the call to create an instance of the remote object is CreateObject(&quot;ProgramID&quot;), but I also see mention of CreateObject(&quot;ProgramID&quot;,&quot;ServerName&quot;). Which is correct? And, more importantly, what does the Program ID and ServerName refer to? Is ServerName the IP of the remote machine? Where do I get the information for ProgramID and ServerName from?

I really would appreciate some help here. As you all must have realized by now, I am very new to the world of DCOM. Up till a few weeks ago, I didn't even know how to create a regular COM component. Any help will be appreciated.

Thanks.

Roonie1
 
Hi, Roonie1 again.

I came across an article by MSDN which explains it all, if one wishes to develop DCOM components in VB.


In this article, a very simple example is given showing how to create and package DCOM components. In fact, its so simple that anyone with even the most basic knowledge of VB will be able to follow it. The method outlined in this article also doesn't require the user to run CLIREG32 on the client side on the VBR file, nor REGSVR32 on the server side on the DCOM component. It also doesn't require the use of MTS.

Just thought I'd share my discoveries.

Thanks and good luck to all.

Roonie1

&quot;Love for All, Hatred for None&quot;
 
Hi
i have a problem with com+ application.
i was able to install com+ application( i.e msi file) on
client programatically using msiexec -i msifilename.
i am having a problem with unistall.

i just want to uninstall com+ application on client programatically so anybody has answer could give me
reply asap.

Thanks

Kumbham

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top