Recall the earlier example on.NET remoting, in which we created a console application that hosts the remoting objects. To make the remoting objects available to access from clients, we must first start the console application. This is perfectly all right during development. It is no trouble at all to take the extra step to start the hosting application for the remoting objects. That is not the case when we deploy the application in a production environment. Users expect your remoting objects to be up and running after they turn on the machine. If you used the same console applications to host your remoting object, the system administrator would have to log on the machine and start each console application one by one in order for the remoting object to work, and they would have to repeat this process each time the machine reboots. Even after the console applications are started, they can be accidentally turned off by closing the console window. Running your application on the console also has security implications. When the administrator logs on the machine and starts your applications, you application will be running under the identity of the administrator. Some administrators prefer to use the local administrator account, while others prefer the domain administrator account. So your application may have either too little or too much privilege with respect to what it actually needs.
KeywordsService Application Configuration File Business Logic User Account Main Thread
Unable to display preview. Download preview PDF.