Discussion Locked

How to run server's DLL from client?

0 helpful
13 replies
Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.
Besides using MTS, is there anyway that i can ask my VB application (which is also installed in the server) to use the DLLs in its same folder? all the client computer will have a shortcut placed on their desktop in order to run the VB app. a full installation for the necessary components will be done on each client computer, however some of the ActiveX DLLs are still under development/testing, therefore i dun wish to include the DLLs in the installation package becos those DLLs will be updatedfrom time to time. there are around 200+ client computers, i dun want to keep updating their DLLs after periodical modifation from the source. since the EXE will be placed in the server, is there anyway that i can hardcode the VB application to search for the DLL from its own folder in the server rather than locally from the client computer?

13 replies

by timthetoolman

Hi,

Although I haven't tried it to confirm it works, I'd say you should be able to add the network drive to your path.

For example, your path may look...

C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;N:\WhereTheDllsAre

Give it a try, anyway. The only down point may be that it causes the PC to seemingly hang and need to timeout on some operations, if for some reason the network is down. And may cause a lot of unnecessary network traffic.

I wonder if you could dynamicallyadd it to the path before running the application and then remove it afterwards? That might be better...

Cheers,
Tim.

by data ninja

You should make "absolute" references to the DLL in the program via a common mapped/shared location, rather than using the object reference library for that DLL. Of course, this requires a great deal of extra typing/coding in the project but will allow you to force the program to look in only the specified location.

by ohjani

Robert,
yes, this is what i want, but how? where can i get a sample code for 'making absolute reference location' in my program?

by timthetoolman

Hi,

Errr... If you're going to do that (hardcoded paths) then I would suggest that you read that value from an ini file so it can be changed without a recompile at least...

I'm sure I'm preaching to the converted, though. :-)

Cheers,
Tim.

by timthetoolman

Hi,

It sounds like you're stuck on going with the other suggestion, but have you considered deployment?

You *can* in fact define the path statement within a process and have it apply to that process and its subprocesses alone. So none of my earlier concerns were valid...

Here is an example which also demonstrates that you can have a network drive in your path...

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

E:\Documents and Settings\Tim Medhurst>path
PATH=E:\Perl\bin\;E:\WINDOWS\system32;E:\WINDOWS;E:\WINDOWS\System32\Wbem;E:\Pro
gram Files\Microsoft SQL Server\80\Tools\Binn\;E:\Program Files\Common Files\Ada
ptec Shared\System

E:\Documents and Settings\Tim Medhurst>cmd
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

E:\Documents and Settings\Tim Medhurst>path=%path%;z:\downloads\temp

E:\Documents and Settings\Tim Medhurst>path
PATH=E:\Perl\bin\;E:\WINDOWS\system32;E:\WINDOWS;E:\WINDOWS\System32\Wbem;E:\Pro
gram Files\Microsoft SQL Server\80\Tools\Binn\;E:\Program Files\Common Files\Ada
ptec Shared\System;z:\downloads\temp

E:\Documents and Settings\Tim Medhurst>pingsx2

E:\Documents and Settings\Tim Medhurst>path
PATH=E:\Perl\bin\;E:\WINDOWS\system32;E:\WINDOWS;E:\WINDOWS\System32\Wbem;E:\Pro
gram Files\Microsoft SQL Server\80\Tools\Binn\;E:\Program Files\Common Files\Ada
ptec Shared\System;z:\downloads\temp

E:\Documents and Settings\Tim Medhurst>exit

E:\Documentsand Settings\Tim Medhurst>path
PATH=E:\Perl\bin\;E:\WINDOWS\system32;E:\WINDOWS;E:\WINDOWS\System32\Wbem;E:\Pro
gram Files\Microsoft SQL Server\80\Tools\Binn\;E:\Program Files\Common Files\Ada
ptec Shared\System

E:\Documents and Settings\Tim Medhurst>

(continued)

by timthetoolman

But why would you want to do this? When it comes to moving the executable to a different server, or maybe failing over to another server, then you simply need to refresh the client's icon on their desk top.

A simple operation that could even be "mail the new icon around".

With an ini or reg entry, then your system administrator's job of moving an application on the server becomes much more difficult. And it may be simpler to ask each person to reinstall rather than try to describe what to do with the supplied ini file or having to write a utility for them to run to update the registry.

With the application itself doing this path definition, then the only path information you need at the client end is in the icon that fires up the application itself.

Your call. Are there any compelling reasons to hardcode paths in it? Is it easier?

Cheers,
Tim.

by ohjani

TimTheToolMan,
i'm not saying abt 1 or 2 values that can be stored in the registry or INI file, i'm talking abt hundreds of library functions which the applications may need to use during run time. however the libraries are done/maintained by a specify developer, he can either share the code out for the other programmers to copy, or he can compile them into ActiveX DLLs. the rest of the programmers will be adding this library to their own project and then deploy to the clients. my concern is, what if the library/DLLs are not stable yet? updatings still take place everyday. i've created a shortcut on the client computer to look for the EXE in server, and connection string can be changed dynamicly as well, but what abt the library? atthe moment, it's either the programmers compile the all the EXEs again after library update or update DLLs in each client computer after library update. that's why i was wondering whether i can put the DLL together with EXE (in server) so that i only need to update the DLL whenever necessary without having to compile EXE or update client's computer.

This discussion is closed to new replies.