Referencing a DLL on a central NT server 
Author Message
 Referencing a DLL on a central NT server

Can any-one tell me how to reference a DLL on a central NT server from about
20 client machine EXEs.

DLL & EXEs on the same machine fine but how do you get the EXE to find the
foreign DLL ?

  DCOMCNFG  ???
  Proxy servers ??
  DNS names ??

Any advice or examples would be great.

Thanks in Advance



Sat, 22 Nov 2003 15:34:37 GMT  
 Referencing a DLL on a central NT server
The only way you'll be able to use a dll that's not physically on the same
machine is with MS Transaction Server (MTS).  Remember, a dll is an
in-process component.

HTH,
Larry


Quote:
> Can any-one tell me how to reference a DLL on a central NT server from
about
> 20 client machine EXEs.

> DLL & EXEs on the same machine fine but how do you get the EXE to find the
> foreign DLL ?

>   DCOMCNFG  ???
>   Proxy servers ??
>   DNS names ??

> Any advice or examples would be great.

> Thanks in Advance



Mon, 24 Nov 2003 08:47:52 GMT  
 Referencing a DLL on a central NT server
That's absolutely not true. All of my source is on our server and when I
build, the dll's end up on the server... so their registry entries point
there and they are instantiated from there. They're not running on the
server, just loaded from there... If you fire up your machine and browse to
the server (or another computer) and register a component, you shouldn't
have any problems... outside of the obvious network speed overhead.


Quote:
> The only way you'll be able to use a dll that's not physically on the same
> machine is with MS Transaction Server (MTS).  Remember, a dll is an
> in-process component.

> HTH,
> Larry



> > Can any-one tell me how to reference a DLL on a central NT server from
> about
> > 20 client machine EXEs.

> > DLL & EXEs on the same machine fine but how do you get the EXE to find
the
> > foreign DLL ?

> >   DCOMCNFG  ???
> >   Proxy servers ??
> >   DNS names ??

> > Any advice or examples would be great.

> > Thanks in Advance



Mon, 24 Nov 2003 22:54:04 GMT  
 Referencing a DLL on a central NT server
OK, so you've got a mapped drive and that probably works fine for just
*your* machine.  Basically, your mapped drive is being treated as if it were
fixed.  I can see that.  But, the original question was 20 clients hitting
the same dll on a "server".  To map 20 clients to the same location on the
LAN and register the dll on each machine is an amateur solution at best.
Wouldn't scale well, would suck to deploy/maintain/support, and I'd be
willing to bet at least one of the users will disconnect the mapping and
wonder why the app. won't work..

This is a definite MTS candidate.  He says he has an NT server, MTS won't
cost anything extra...seems obvious to me...

Just my two cents.


Quote:
> That's absolutely not true. All of my source is on our server and when I
> build, the dll's end up on the server... so their registry entries point
> there and they are instantiated from there. They're not running on the
> server, just loaded from there... If you fire up your machine and browse
to
> the server (or another computer) and register a component, you shouldn't
> have any problems... outside of the obvious network speed overhead.



> > The only way you'll be able to use a dll that's not physically on the
same
> > machine is with MS Transaction Server (MTS).  Remember, a dll is an
> > in-process component.

> > HTH,
> > Larry



> > > Can any-one tell me how to reference a DLL on a central NT server from
> > about
> > > 20 client machine EXEs.

> > > DLL & EXEs on the same machine fine but how do you get the EXE to find
> the
> > > foreign DLL ?

> > >   DCOMCNFG  ???
> > >   Proxy servers ??
> > >   DNS names ??

> > > Any advice or examples would be great.

> > > Thanks in Advance



Tue, 25 Nov 2003 04:54:08 GMT  
 Referencing a DLL on a central NT server
No... I don't have a mapped drive.. well I do but that has nothing to do
with it.. and it doesn't point to my source folders anyway... and my dll's
are registered to \\Server01\DDrive\yada\yada which would remain constant on
any machine connected to the network and would fail only if the server is
down.. and I don't care if 100 users are instantiating the dll.. It's easy
enough to deploy too.. just create a setup package and deploy to the server
(it's one of the choices of the deployment wizard).. As soon as the first
user does this, the files will be there and their registry set.. when
additional users do it, the files are there already so setup will skip that
and just set the registry.. works for me...


Quote:
> OK, so you've got a mapped drive and that probably works fine for just
> *your* machine.  Basically, your mapped drive is being treated as if it
were
> fixed.  I can see that.  But, the original question was 20 clients hitting
> the same dll on a "server".  To map 20 clients to the same location on the
> LAN and register the dll on each machine is an amateur solution at best.
> Wouldn't scale well, would suck to deploy/maintain/support, and I'd be
> willing to bet at least one of the users will disconnect the mapping and
> wonder why the app. won't work..

> This is a definite MTS candidate.  He says he has an NT server, MTS won't
> cost anything extra...seems obvious to me...

> Just my two cents.



> > That's absolutely not true. All of my source is on our server and when I
> > build, the dll's end up on the server... so their registry entries point
> > there and they are instantiated from there. They're not running on the
> > server, just loaded from there... If you fire up your machine and browse
> to
> > the server (or another computer) and register a component, you shouldn't
> > have any problems... outside of the obvious network speed overhead.



> > > The only way you'll be able to use a dll that's not physically on the
> same
> > > machine is with MS Transaction Server (MTS).  Remember, a dll is an
> > > in-process component.

> > > HTH,
> > > Larry



> > > > Can any-one tell me how to reference a DLL on a central NT server
from
> > > about
> > > > 20 client machine EXEs.

> > > > DLL & EXEs on the same machine fine but how do you get the EXE to
find
> > the
> > > > foreign DLL ?

> > > >   DCOMCNFG  ???
> > > >   Proxy servers ??
> > > >   DNS names ??

> > > > Any advice or examples would be great.

> > > > Thanks in Advance



Tue, 25 Nov 2003 05:18:16 GMT  
 Referencing a DLL on a central NT server
Actually, I stuck my foot in my mouth on that one... Visual Installer can
build setups that can be installed to the server... not the PDW.. But
still.. it does work.. and you could probably coerce the PDW to do it as
well..


Quote:
> No... I don't have a mapped drive.. well I do but that has nothing to do
> with it.. and it doesn't point to my source folders anyway... and my dll's
> are registered to \\Server01\DDrive\yada\yada which would remain constant
on
> any machine connected to the network and would fail only if the server is
> down.. and I don't care if 100 users are instantiating the dll.. It's easy
> enough to deploy too.. just create a setup package and deploy to the
server
> (it's one of the choices of the deployment wizard).. As soon as the first
> user does this, the files will be there and their registry set.. when
> additional users do it, the files are there already so setup will skip
that
> and just set the registry.. works for me...



> > OK, so you've got a mapped drive and that probably works fine for just
> > *your* machine.  Basically, your mapped drive is being treated as if it
> were
> > fixed.  I can see that.  But, the original question was 20 clients
hitting
> > the same dll on a "server".  To map 20 clients to the same location on
the
> > LAN and register the dll on each machine is an amateur solution at best.
> > Wouldn't scale well, would suck to deploy/maintain/support, and I'd be
> > willing to bet at least one of the users will disconnect the mapping and
> > wonder why the app. won't work..

> > This is a definite MTS candidate.  He says he has an NT server, MTS
won't
> > cost anything extra...seems obvious to me...

> > Just my two cents.



> > > That's absolutely not true. All of my source is on our server and when
I
> > > build, the dll's end up on the server... so their registry entries
point
> > > there and they are instantiated from there. They're not running on the
> > > server, just loaded from there... If you fire up your machine and
browse
> > to
> > > the server (or another computer) and register a component, you
shouldn't
> > > have any problems... outside of the obvious network speed overhead.



> > > > The only way you'll be able to use a dll that's not physically on
the
> > same
> > > > machine is with MS Transaction Server (MTS).  Remember, a dll is an
> > > > in-process component.

> > > > HTH,
> > > > Larry



> > > > > Can any-one tell me how to reference a DLL on a central NT server
> from
> > > > about
> > > > > 20 client machine EXEs.

> > > > > DLL & EXEs on the same machine fine but how do you get the EXE to
> find
> > > the
> > > > > foreign DLL ?

> > > > >   DCOMCNFG  ???
> > > > >   Proxy servers ??
> > > > >   DNS names ??

> > > > > Any advice or examples would be great.

> > > > > Thanks in Advance



Tue, 25 Nov 2003 05:32:45 GMT  
 Referencing a DLL on a central NT server
One more chunk of coal for the fire :).. Here, all developers are *required*
to keep the components registered on the server so anyone that creates an
InstallShield setup, uses the latest components, which saves all from having
to keep all required / updated dlls on the local machine and kills alot of
versionitis problems we'd no doubt have otherwise. Now all we worry about is
some bone head forgetting to set Binary Compatibility.. ;)


Quote:
> Actually, I stuck my foot in my mouth on that one... Visual Installer can
> build setups that can be installed to the server... not the PDW.. But
> still.. it does work.. and you could probably coerce the PDW to do it as
> well..



> > No... I don't have a mapped drive.. well I do but that has nothing to do
> > with it.. and it doesn't point to my source folders anyway... and my
dll's
> > are registered to \\Server01\DDrive\yada\yada which would remain
constant
> on
> > any machine connected to the network and would fail only if the server
is
> > down.. and I don't care if 100 users are instantiating the dll.. It's
easy
> > enough to deploy too.. just create a setup package and deploy to the
> server
> > (it's one of the choices of the deployment wizard).. As soon as the
first
> > user does this, the files will be there and their registry set.. when
> > additional users do it, the files are there already so setup will skip
> that
> > and just set the registry.. works for me...



> > > OK, so you've got a mapped drive and that probably works fine for just
> > > *your* machine.  Basically, your mapped drive is being treated as if
it
> > were
> > > fixed.  I can see that.  But, the original question was 20 clients
> hitting
> > > the same dll on a "server".  To map 20 clients to the same location on
> the
> > > LAN and register the dll on each machine is an amateur solution at
best.
> > > Wouldn't scale well, would suck to deploy/maintain/support, and I'd be
> > > willing to bet at least one of the users will disconnect the mapping
and
> > > wonder why the app. won't work..

> > > This is a definite MTS candidate.  He says he has an NT server, MTS
> won't
> > > cost anything extra...seems obvious to me...

> > > Just my two cents.



> > > > That's absolutely not true. All of my source is on our server and
when
> I
> > > > build, the dll's end up on the server... so their registry entries
> point
> > > > there and they are instantiated from there. They're not running on
the
> > > > server, just loaded from there... If you fire up your machine and
> browse
> > > to
> > > > the server (or another computer) and register a component, you
> shouldn't
> > > > have any problems... outside of the obvious network speed overhead.



> > > > > The only way you'll be able to use a dll that's not physically on
> the
> > > same
> > > > > machine is with MS Transaction Server (MTS).  Remember, a dll is
an
> > > > > in-process component.

> > > > > HTH,
> > > > > Larry



> > > > > > Can any-one tell me how to reference a DLL on a central NT
server
> > from
> > > > > about
> > > > > > 20 client machine EXEs.

> > > > > > DLL & EXEs on the same machine fine but how do you get the EXE
to
> > find
> > > > the
> > > > > > foreign DLL ?

> > > > > >   DCOMCNFG  ???
> > > > > >   Proxy servers ??
> > > > > >   DNS names ??

> > > > > > Any advice or examples would be great.

> > > > > > Thanks in Advance



Tue, 25 Nov 2003 05:49:29 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. Referencing DLL on a central NT server

2. Internet Server Error : In Project Central Server

3. Project Central-Server Trial / Integrating Macs in Project/Exchange-Server Enviroment

4. Cannot upload project to Project Central Server

5. Running from Server or Central Location

6. Date and Time from a central server

7. NT workstationN Nt or T or server NT

8. ActiveX dll behavior with IIS 4.0 on NT server

9. ActiveX dll behavior with IIS 4.0 on NT server

10. DCOM from an Access95 VBA Application to a DLL on an NT Server

11. Deploying dll to nt server

12. ActiveX dll behavior with IIS 4.0 on NT server

 

 
Powered by phpBB® Forum Software