>> 1. Improved reliability by isolating components within their own process boundary.
I disagree, you can isolate components by loading them into separate AppDomains. >> 2. Improved manageability by giving each EXE its own config file. Managing a single config file for many DLLs is becoming error-prone. Agree, but you can come up with a solution which allows each component to be configured via a separate file yourself. >> 3. With the DLL-approach, you'd have to stop the host exe to update a DLL, whereas with EXE, you only need to stop a single EXE. Disagree, see point 1 - you can unload an AppDomain at any time. >> On the down side: >> 1. Because communication between server-side components themselves is minimal and sometimes non-existent, the issue of performance due to EXEs communicating with each other does not weigh much. Agree, AppDomains within a single process hurt performance as much as cross-process. >> 2. Increased manageability, but we've already implemented a simple GUI to stop/start individual server-side EXEs in case of a crash. Can't really comment on this one, but I think you'll better with separate AppDomains, because you can trap AppDomain errors and unload/re-load the faulty AppDomain automatically. HTH and cheers, Stoyan -----Original Message----- From: Unmoderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Diranieh, Yazan Sent: Thursday, December 09, 2004 10:27 AM To: [EMAIL PROTECTED] Subject: [ADVANCED-DOTNET] Distributed Application Design - Using EXEs instead of DLLs for s erver-side components We have a client/server .NET distributed application with server-side components currently implemented as DLLs and running within a single process on the server. Clients talk with these server-side components via .NET Remoting. The current thinking is to convert major server-side DLLs into outright server-side EXEs. Rational being: 1. Improved reliability by isolating components within their own process boundary. 2. Improved manageability by giving each EXE its own config file. Managing a single config file for many DLLs is becoming error-prone. 3. With the DLL-approach, you'd have to stop the host exe to update a DLL, whereas with EXE, you only need to stop a single EXE. On the down side: 1. Because communication between server-side components themselves is minimal and sometimes non-existent, the issue of performance due to EXEs communicating with each other does not weigh much. 2. Increased manageability, but we've already implemented a simple GUI to stop/start individual server-side EXEs in case of a crash. Does anybody have serious issues with this approach where logically-isolated server-side DLLs are converted into server-side EXEs? Yazan.Diranieh - 0 error(s), 0 warning(s) www.diranieh.com ======================================================================== ====== This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. ======================================================================== ====== =================================== This list is hosted by DevelopMentorR http://www.develop.com Some .NET courses you may be interested in: Essential .NET: building applications and components with C# November 29 - December 3, in Los Angeles http://www.develop.com/courses/edotnet View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor� http://www.develop.com Some .NET courses you may be interested in: Essential .NET: building applications and components with C# November 29 - December 3, in Los Angeles http://www.develop.com/courses/edotnet View archives and manage your subscription(s) at http://discuss.develop.com
