RFC: Specifying services in the configuration file

Topics: CAB & Smart Client Software Factory
Jan 26, 2006 at 3:18 PM
originally posted by: kozaczynski

This is the first RFC (Request For Comments) thread an we will be creating many of them in the future. The idea, as the name implies, is to get your input on a request or a problem that we may need to address.

In this particular case we would like to get your comments on the following question: How can I specify a service in the configuration file and load it at the client application start-up time?

What we would like to know the most is the “why”. What are the scenarios that require that capability? How common are those scenarios? What are the kinds of services that change outside of the client update cycle?
Jan 26, 2006 at 3:52 PM
originally posted by: PProvost

If I may clarify a bit...

We know that a CAB application allows you to load CAB services into the root dependency injection container via the app.config file. We also know that you can specify them in the application class in the code itself.

Clarifying Questions:

- Why would you choose one over the other for YOUR application?

- What is the scenario that you are thinking of that leads you to your decision?
Jan 26, 2006 at 4:22 PM
originally posted by: PJackson

We are currently developing several applications based on the CAB. As part of this effort we're creating a common shell application and shell form. Our intent is that a given project will inherit the application from this base, then define its own app.config and profilecatalog for the services and modules specific to it.

So our plan would be to load common services in the ancestor application class, and application-specific services via app.config.
Jan 27, 2006 at 11:01 AM
originally posted by: dallasreb

Based on a current enterprise smart client application, I can see us using both application-specified and config file specified. If we extend the framework with common functionality the all of our in-house applications will use/need, these would probably be handled in the application code.

As for config file use, let me describe a bit on how our current app configures itself that might answer some questions. Note that we are watching both the CAB and BAT projects with an eye toward re-hosting our smart client in the future.

Our current application (after performing any auto-updates as described in another posting) requests a config file from a central web service. The system name is passed so the config returned is specific to the client. Each client can run a different set of plug-ins based on a central management tool. Based on the config file received, the specified plug-ins are loaded and configured. This functionality is not currently handled by the base CAB because the config file must be ready at startup (please let me know if I missed something here).

Ideally I would like to have an integrated loader that can pull assemblies as needed from a server so a full set of extensions don't have to be updated/downloaded when security prevents a user from needing certain assemblies. Maybe a way to register a proxy service, workitem, etc. that will trigger a load on demand?

So I can see a new client loading base services to handle our auto-update process and pulling the configuration. Then it will need to use that config file to load system-specific extensions and start the main part application. It would be possible to divide this among multiple apps such that the startup app handles updates and receiving the configuration then it starts the main app and the config is ready. However, it seems cleaner to me if we can gradually bootstrap the application until it is fully functional. Comments desired...
Feb 3, 2006 at 7:20 PM
originally posted by: headlam

Peter. We have considered both approaches –via the config file and via code. The general consensus is it depends. However, for our enterprise “CAB services” we are opting for the code approach because it gives us some assurance that the services that are expect will be registered (i.e., an admin did not remove the services from the config file – regardless of weather the file is static or dynamic from a web service). We also felt that there was also some level of security associated with doing it imperatively that might not be offered via the configuration approach. Also if someone tries to replace our service (using the same name) via config, we will have an exception which is the behavior we want. We like having the config approach in case we need to change the implementation without recompiling so there might be a certain class of services that falls into this category (i.e., registered via config only… not in code).