CAB Module Configuration

One of the issues we face when developing a composite application is where module specific configuration belongs. There seems to be three approaches to the problem.

1. Put it all in the shell’s app.config. If this is the answer one may want to question why the application is a composite one.
2. Have a build task that merges module config into the app.config
3. Have each module just deal with its configuration in isolation.

Option three is my personal preference as I think this lowers the requirements on possibly already complicated build/deploy routines and gives a level of isolation I associate with a composite application. If we were on the web platform we could just create new application domains for sub domains or sub-directories. How can we give similar isolation for client applications?

The .Net framework give us the ability to get config setting very easily from the executing assembly’s config using good old System.Configuration.ConfigurationManager. (still annoys me that System.Configuration is a seperate assembly to reference).

However using the  ConfigurationManager in the default manner is of no use in the composite application world. We have to look to some of its other features to get what we need.  ConfigurationManager provides a (somewhat misleading) method named OpenMappedExeConfiguration.  It actually allows access to non executable assemblies ie a dll. In this example we use the standard of a “.config” suffix to an assembly name to identify the module config.

    ExeConfigurationFileMap map = new ExeConfigurationFileMap();
    map.ExeConfigFilename = this.GetType().Assembly.Location + ".config";
    if (File.Exists(map.ExeConfigFilename))
    {
        _configuration = ConfigurationManager.OpenMappedExeConfiguration(map, ConfigurationUserLevel.None);
    }

Now our _configuration variable can be used in a similar fashion to ConfigurationManager. We have access to our old favorite properties AppSettings and ConnectionStrings. We also can get config sections by using the GetSection method.

Hope this little insight helps building your composite applications in a little bit more isolation.

*Thanks to Grae for the base code.

Strong typed CAB events

Out of pure guilt of not posting for 6 months (wow lazy), I thought i had better share some love. Having been in the CAB space for a while and followed the EventTopics constants file pattern we have found that it can get very loosey goosey and have created a new pattern. Only argument less events are defined in the EventTopics constants. Ie anything that just takes EventArgs.Empty goes in here. ///

/// Public CAB events that only require empty . /// public class EventTopicNames : MyCompany.Cab.Infrastructure.Interface.Constants.EventTopicNames { ///

/// The CAB event string to use to launch a customer search use case. /// /// /// Only need to be provided as the event arguments. /// public const string LAUNCH_CUSTOMER_SEARCH = "MyCompany.Examples.MyCustomerModule.Interface.LaunchCustomerSearch"; } However if you need arguments passed with your event different rules apply. First, never use generic EventArgs. What a stupid idea generic EventArgs are. Take the 30seconds out of your life and create a strongly type event arg. Good practice tells us that in general it should be immutable so you can set the private field backing stores to readonly. Next provide arguments in the constructor to set any properties and then expose the properties. Also, seal the class as I bet no-one will want to inherit from you ultra specific CAB event arg. Now, the event topic name belongs on this class. This now makes the whole thing so much more cohesive and discoverable. public sealed class LaunchCustomerEditEventArgs : System.EventArgs { public const string CAB_ID = "MyCompany.Examples.MyCustomerModule.LaunchCustomerEditEventArgs"; private readonly int _customerId; public LaunchCustomerEditEventArgs(int customerId) { _customerId = customerId; } public int CustomerId { get { return _customerId; } } } Here I have used the convention of "CAB_ID" to expose the event topic name. That is just to satisfy the coding standards for the current company. I would prefer it to be "EventTopicName" . Remember this needs to be constant so that it can be used in attribute on you publications and subscriptions. As it needs to be public and constant, changing it is a breaking change and requires all your dependant assemblies to recompile. To avoid the need to change it please give it a truly unique value. A good option is to use the full type name of the EventArgs.

Betting on the wrong platform - Web vs. Smart Client

I am currently working on a smart client app that is to service a company and thousands of its employees over a large geographic area. From what I understand the reasons to go smart client instead of web was

• It would be faster
• A far better UI experience could be provided
• It would scale better

In reality we faced some issues

• steep learning curve making a transition from ASP.NET or WinForms to WPF
• steep learning curve with CAB
• steep learning curve making a transition from Web Services to WCF
• CAB+ WPF left the team using an essentially unsupported piece of software
• less time left to worry about things that matter like security &performance

The current state of "Web 2.0" makes it really hard to justify a smart client app. Removing the requirement for offline, because In the end we didn’t even implement offline (one of the 5 characteristics of a Smart client ), initially give the perception of an even playing field. However:

• ASP.NET seems to be the number one skill developers have. No need to learn CAB and WPF.
• Deployment issues just go away. We actually had very little in the way of problemswith deployment mainly just the size of the DLLs.
• The UI argument is pretty much dead with Silverlight, Ajax, JavaScript and CSS. I can’t at the moment think of a requirement for a Banking application to require thefull power of WPF that can not be performed by the above web technologies.
• Any performance issues we had were related to either the amount of data being returned from the service or the impact the CAB and WPF just have. These maybe due to our lack of knowledge of WPF and CAB but we think we are pretty much on top of it now after 12months of dev. Data communication performance should be moot as using Ajax essentially negates an argument for or against. Loading modules which is slowing CAB down wouldn’t be a hassle for the web implementation.

Retrospectively I get the feeling the app we have built so far could have been done in ASP.NET with less developers in a quicker time frame with less defects. The resulting product would be remarkably similar though. This also then gives me the sinking feeling that I have invested a lot of time in to a rather dead-end framework instead of keeping up with our peers in the ASP.NET world. Flip side; maybe I now have a niche skill that makes me a commodity?