Install exe/dlls on each client or on the server? 1

[SJG0526]

I developed a multiuser vb.net windows forms app that will be run in a network environment. I put the exe, dlls and config file on the server in a new folder. I installed the .net framework and MDAC 2.8 on one client pc to test. The app links to a MS Access database residing on the server.

I clicked the exe and get a securityException error which I understand can be corrected by making it a trusted assemby in .net configuration.

Question:
1. Should the exe and dlls be on the server or on each client pc?
2. If on the server, do I need to set the trusted assembly from each pc? and does .net framework need to be on the server?
3. If on the client, whats the best way to deploy changes? Another company handles the server setup and I don't know if I can do a no-touch deployment - but is this the way to go?
4. What's the best way for speed and multiuser use?

Thanks!

 

[chrissie1]

1. Your choise, but mine would be to put them on the clients (less network traffic, faster starting of app)
2. framework needs to be on server.
3. I wrote my own update routine, where the app checks for a newer version on the server in a shared folder somewhere and then installs the new version if needed. But you could also use this

http://www.vbcity.com/forums/faq.asp?fid=41&cat=General&#TID80211.

Or something else.
4. see 1. Depends of course on how many clients you got.

Christiaan Baes
Belgium

If you want to get an answer read this FAQ faq796-2540
There's no such thing as a winnable war - Sting

 

[pweegar]

Maybe I'm a bit confused here. But don't .dll's need to be on each client and registered by each client? If not, how does the client use the .dll????

This means that the net framework would need to be loaded on each pc, along with exe (and I agree, it would cut down tremendously on network traffic, esp. as the number of users grow and the tables grow, esp. with Access and it's desire to move entire recorsets over the network..argh)

I'd also place static tables on each pc. Why burden the network with data that very seldom if ever changes?

 

[chrissie1]

pweegar it is also possible to place the exe and dll's on the server and run it from there.

Christiaan Baes
Belgium

If you want to get an answer read this FAQ faq796-2540
There's no such thing as a winnable war - Sting

 

[pweegar]

I know it's possible to run exe from a server, but how does trhe client know anything about the dll a program needs.

I'm trying to think of any app I use that works this way and can't. In fact I have a web browser application that loads a custom viewer in the form of a dll and it MUST install on each pc as an ActiveX control....

I can see many reasons for NOT keeping dll on a central server, esp. in a large network environment. The network traffic can be horrible. And users complaining is something I really don't need (in a building with approx. 2000 employees)

 

[ThatRickGuy]

.Net dlls don't need to be registered, only COM components do. And as for why to do a network roll deployment instead of local, it metters on the environment. We have 800+ PCs in 5 different branchs. Going to each machine to install an update would be impossible, and getting the network guys to time an enterprise wide deployment would be pretty unlikely. By using a network deployment, or a system like Chrissie mentioned (which is what I'm trying to talk my boss into) you don't have to worry about rolling out the new application. You just have to update a file on the network, or a database entry.

-Rick

----------------------

http://www.ringdev.com

 

[SJG0526]

Thanks for the suggestions everyone. I will have only about 10 users max. I will look into chrissie1's link as it sounds like a good idea. That would put the dlls and exe on the clients and keep them updated. I assume then that the .net framework wouldn't need to be on the server then since the server would just serve up data from the mdb, right? Anyway, it should already be there if the network guys are applying their server updates, correct? Oh, its Windows Server 2000 or 2003.

Having multiple exes will be ok as far as multi-user contention, right?

 

[ThatRickGuy]

The server doesn't need to have the .Net framework installed. Even if you're using a No-Touch web deployment, the server doesn't need it.

Infact, unless you are specifically running .Net apps on the server, it shouldn't be. Having extra services running or available on servers is usually a bad idea as it can leave you more vulnerable to security breaches.

-Rick

----------------------

http://www.ringdev.com

 

[chrissie1]

windows 2003 server already has the framework. But no the server wouldn't need it. I guess the framwork is in one of the windows 2000 server service packs as well, but I don't know wich one.

you should be ok with 10 users and access normally access will only take 5 users at a time, so keep the connections as short as possible. and you won't have a problem.

so open the connection get the data and close the connection.

Christiaan Baes
Belgium

If you want to get an answer read this FAQ faq796-2540
There's no such thing as a winnable war - Sting

 

[miket26]

What are the DDLs? If they are forms or other classes you created, then I would say definately store them in one location, and have the clients load them at runtime. I have an app that does this for 15 clients, and it works great. I got the idea from reading an article on MSDN called Loading classes on the Fly. It works very easily for Form classes, and any other other class ( but for these other types you have to create an interface between your application and the class stored in the DLL). Check it out...

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnadvnet/html/vbnet10082002.asp