Config And Code and Bears! Oh My!

Where I am working right now, there is a need for framework configurations that are different from application configurations. I should alter that to say, it is not a need, but a desire. The main endpoint here is there are certain configuration elements only people who are very well trained in framework should edit, so a separate set of configs hides this from the end user developer. I am not sure I personally agree with this, but it is what it is. This comprises the first part of the “equation” that prompts this entry.

The second part of the “equation” is the use of IoC containers, in particular StructureMap, so different implementations of an interface can be spun up at run time. In the latest versions of many IoC Container projects, the container is populated using registries coded in a .NET language. You  then discover the many “registries” and spin them up at run time.

Let’s look at the two issues separately and I will try not to go ADHD and find too many shiny things to add to the entry.


In .NET today, you have the ability to set up multiple configurations for an web application without any work on the part of the developer, other than adding the specifics to configuration. Out of the box, you have a configuration for debug and release, as in this web application:


It is a bit too bad you don’t automagically get this for all project types, but it is a foundation that can be built on. And, you can add additional specific configurations by simply adding new configuration definitions. Unfortunately, this has to be done at the global level, prior to creating the project, as there is no automagic “oh you have a new configuration and I need a specific config file” type of functionality. If you have just started a new project, you can delete the web config, create new configurations (Build >> ConfigurationManager) and adding:


If I then add a web configuration file, I see the new configurations:


Beyond the small bits above, the how of setting up new types, extending to other project types, etc., is beyond the scope of what I am talking about in this post. Just know that there is a system in place, at least for web application, and you can manually add to this system.

NOTE: The bits behind the multiple build configurations has more bells and whistles than this simple example. If you need this type of functionality, Google and you will find many examples.

On the current project I am working on, there are two concepts this does not solve.

  1. Hiding internal (framework) configurations from the end user developer
  2. Allowing customization of configuration at more than 2 levels

The end game looks something like this.


For the record, I am not fond of hiding configuration bits from end user developers. Sure, someone whacking configuration can cause problems that fall back on the team, but when the config is in the open, it is easy enough to say “didn’t I tell you NOT to do this?” … as long as you have it documented, that is. I don’t believe in using obfuscation through obscurity or hiding as a means of controlling “bad” behavior (was: technology does not solve process problems). As an analogy, is it better to hide a gun from your user, knowing a clever user might still find it, or send the user to a gun safety course? I vote for the later (neither will save you from someone “going postal” in their code, of course, but that is another story).

I am also not convinced that customization at multiple levels is a need. It is a nice thought exercise, but the actual use cases where it is NEEDED are very small, perhaps even non-existent. I am separating wants from needs, as there are probably others who WANT a multiple level “configuration conglomerator” piece. Assuming you actually NEED something like this, I can offer a few suggestions:

  1. Consider moving the configuration processor to build time, so the combined configuration file appears in the /bin folder. If you want to obfuscate through obscurity, to hide elements from the developer, you can’t use this, but I have stated my feeling about hiding the gun, where he can still find it, over sending the user to a gun safety course.
  2. Write out the end configuration, even if the configuration is completely pulled from memory at run time. if you have the file dumped, you have the ability to read through it and discover where the problem lies without searching or debugging. In fact, if you make a tool that creates config for all enviroments you can check before you deploy (defensive deployment – what a freaking concept!).

Coded Configuration

On the project, IoC containers are also used. For those not familiar with IoC containers, they are essentially a property bag of concrete implementations for an interface, with a factory to produce the concrete implementation. The general scenario is configure a variety of concrete implementations for your interfaces as the application bootstraps which are then used at runtime. Every IoC Container I know allows the developer to either explicitly implement a concrete implementation (by name, for example) or have it automatically get the correct instance based on configuration and rules.

We are using StructureMap currently, and it has the idea of a coded “registry” to set up the IoC Container “property bag”. Essentially, this means the bits you would normally have in a configuration file are now coded and included in your library.

The positive side of coded registries is you can offer multiple implementations out of the box, so the developer simply calls the correct one (based on how you have set up, so perhaps by name, but perhaps by another means – not important for now).

The negative side is when they have to be overwritten at the application level. It is not a big deal if you have one framework coded implementation that is overridden by a single application, but it can be overly complex once you start stacking different layers, as the config files were in an earlier picture. If anything is loaded in the wrong order, you can end up with a disaster. And catching these types of mistakes involves setting up your own instrumentation.

I am not fond of complex systems. I am less fond of adding multiple complex systems on top of each other. That leads to …

Code Versus Configuration Files

I was not going to jump on this when I initially jumped into this entry, but code versus configuration files is an age old question. In UNIX, files are the norm, even beyond configuration. In MS-DOS and early windows, you had the .ini file. As we started into the NT age, the idea of registry came about for configuration and in the COM age, the registry helped facilitate DLL hell. When we moved to .NET, we went back to configuration files. Now, many of the projects are going to coded configurations (like the registries in StructureMap).

ADHD moment: I personally can see an argument for both types of methodologies, but you have to set some rules around their use. In my world, a good delineation would be to use the registry to offer instances and then configure with a file in your application. Or perhaps, you are releasing a library as a product (internally or for sale) that contains multiple implementations. This is especially true if you don’t see the average user extending the system. If so, I would likely argue for configuration files again. Smile NOTE: The specific examples above are unimportant to the post beyond giving a mental picture.

Back to our regularly scheduled show: What is dangerous is when you end up with part of your configuration in a configuration file and the rest in some coded construct. If you have to add a lot of flexibility to your configuration, then it is probably best to leave everything in configuration, with the shipped library as product being a possible exception. A single multiple file/step process is better than 2, especially if the processes are complex.

Disagree? I accept that may be true where you are, but I see this in practice where I am today. An application is working fine in staging and it goes to production and something goes to hell in a hand basket. If I have a domain expert, he might be able to say “that is config” or “that is IoC”, but a non-expert will have to step through things. And, when you have multiple complex systems you either force rollback or increase downtime. Ouch!

Actually, I will punch the baby for a bit. I am not sure I agree that going back to coded configuration is a good idea, except perhaps as packaged software. But, even with the packaged bits, I see Microsoft stating “if you add this, you have to add this to configuration”, so the precedence is “allow the user to customize configuration and guide them”. And, you can create VS tools or templates to add the bits, so it is not a huge deal.

I also find that hiding all of the bits to solve the package problem, but creating a huge extensibility and perhaps maintainability problem is a big mistake. And, I find many who move away from this direction do it simply because they don’t like to write documentation and guide users/developers. Is this really wise?

Note I am not against the registry concept completely, I just don’t see value in most of the scenarios I see it being used in. I see it adding more complexity for very little benefit, at best.


I probably sidelined a bit and this ends up more as a rant, but let me see if I can make some points that you might be able to take home.

  1. If you find you are using multiple systems to configure an application, consider refactoring to one. In fact, seriously consider it.
  2. If you are packaging a utility library with multiple implementations (perhaps a SQL versus Oracle versus MySQL), you can considering moving this out of the registry. Consider the extensibility likelihood in the mix, however, as you may make your software hard to extend in the process of making “use it out of the box” an easy scenario.
  3. In everything in software, consider all of the needs before firmly committing to a direction, especially a direction that adds complexity.

Feel free to comment, as I would love other points of view. This is a random post and I am going into more of the “Core as Application” direction in the next series I will start shortly.

Peace and Grace,

Twitter: @gbworld

The Future is HTML5

Just recently, a list I belong to had a discussion on Windows 8 applications. At one point, the thread grew a bit philosophical and the possibility (or fact?) that HTML5 was the future was presented. This spurred quite a bit of discussion.

If asked, I would state that HTML5 is the future, but disagree with the statement “HTML5 is THE future”. As a developer, especially were I strictly a UI developer, I think it would be stupid to not learn HTML5 now and stay somewhat ahead of the curve. Why stupid? Multiple reasons:

  1. HTML5 is the next rich web technology
  2. With tools like PhoneGap, HTML5 is a decent mobile UI technology
  3. With Microsoft using HTML5 for Windows 8, it is a UI technology that takes you to the most popular desktop
  4. So, yes, HTML5 is the future. But this future is not necessarily an exclusive future. In fact, if it is, then the advanced developers of the world, especially the teachers, trainers and speakers, have done a piss poor job of mentoring up the next wave of development professionals.

    Silverlight and WPF

    When you have a discussion with Microsoft developers about HTML5, comparisons with Silverlight are inevitable. And, with so much overlap, I think Silverlight is dead, at least in its current incarnation. Unless Microsoft is willing to go head to head with HTML5 and make Silverlight a standout (a move they have not made to date), why would someone choose XAML over the markup in HTML5 when HTML5 is so much more portable? Rhetorical, as I realize those who have already invested heavily in learning Silverlight will hang on.

    But, Silverlight could live on as a mini .NET library that the browser can access. In my opinion, this is the strength of Silverlight, even if it is not as sexy as XAML. For this reason, I think Silverlight is on a decline, as far as UI goes, although there is still a potential for life. Perhaps marrying the Silverlight underpinnings with HTML5 will keep Microsoft on the “smart client” side.

    On to WPF. With Silverlight representing most of what WPF can do (it at least hits the 80/20 mark), I don’t see much of a future for WPF. If HTML5 had not already invaded the desktop, I might see a greater need to keep WPF around, but if the desktop UI, the mobile UI and the web UI can be expressed with one technology, why do we need WPF.

    .NET and the rest of the “world”

    Unless JavaScript can become a viable middle tier language, .NET languages are safe, which means it is safe to continue to learn C# or VB. Java is also safe. Both of these are “doubly safe”, at least for the near future, as so much time has been invested in creating applications and training developers. In the long run, it will depend on whether we continue to push SOLID principles, etc., for quality software.

    If we focus on .NET alone, the web form paradigm is in danger if Microsoft does not introduce more HTML5 goodness for web forms. ASP.NET MVC has already embraced HTML5. I see WinForms holding on by a thread, at least until you can create a formed application as easily in HTML5 (Microsoft did a poor job with WPF in Visual Studio, so many did not take the plunge). Once we have tooling, even WinForms will have a difficult time staying afloat.

    Long term, I see .NET, as a framework, safe, provided Microsoft properly positions it and JavaScript is not lifted as an Enterprise paradigm for all “tiers” (in quotes due to my assertion the application is the business logic and UI is a veneer on top – more in other blog posts). There is too much functionality to rewrite and JavaScript, at least in the near term, is a weak language for Enterprise application development beyond the UI. I think Microsoft has to figure out how to make .NET viable on the UI side (HTML5 specs give some options), so the next crop of developers don’t see markup, CSS and JavaScript as the only way to develop.

    Final Words and Advice

    As a developer, I think you need to learn HTML5. If you are a UI developer, this is doubly true, as HTML5 is for the UI. If JavaScript moves into the middle “layer”, all the better for newbies that start their learning with HTML5 as a UI technology, although the idea of JavaScript being the only language makes me cringe as badly as having vanilla as the only ice cream choice or apple as the only pie. Regardless of feelings, HTML5 is going to be around as a web UI technology. With Adobe’s help (PhoneGap), it will comprise a decent chunk of mobile UI development. With Microsoft’s help (Windows 8), it will comprise a decent chunk of Windows UI development.

    Peace and Grace,

    Twitter: @gbworld

Organization is Key to Development

I started out this morning looking at a the Test List Editor on a project I am working on. At the top were a bunch of broken tests with a few live tests. At the bottom were hundreds of live tests, but none were organized. There were 538 live tests and at least twice that many that no longer existed. Ouch!

Unit Test Organization

I am thankful someone pushed the idea of unit testing to the organization, but the lack of organization of the tests gives me pause. What if a developer only wants to run tests for a particular assembly? In the current setup, you have to organize the tests by project and then manually click each of the tests. This is a time consuming effort that has to be repeated each time you have to run the tests.

Fortunately, this nightmare can be solved in Visual Studio by simply placing tests into lists. You can then run the tests in isolation rather than running every single test in the entire suite. At minimum, I would focus the tests on area and break down so unit tests and integration tests (if any) are separated. Further separation may be needed to test specific functionality. Another possibility is starting with tests that run for a build and those that don’t. The important takeaway is you should organize your tests. Below is an extremely minimalist approach I took in a recent project.


In case the above seems a bit strange, I use a modified BDD style when testing. I say modified as I use the default MSTest bits and organize by behaviors. Why is a topic for another blog entry.

In short, if you are going to create tests (and you are, right?), you need to keep the tests organized. If you need an analogy, think of the test list editor like a library. Unless the books are ordered so you can find them, they are worthless. Every library needs a librarian, which brings me to the next topic.

Other Organization Needs

Another clear organization need in every development shop is a clean way of organizing documentation and other artifacts. One of the most popular tools for organizing content is SharePoint. And nearly everywhere I go I find something like this:


Pretty standard search and I find numerous items that have absolutely nothing to do with the topic I am searching for. In addition, I find multiple versions of the same document. The second issue can be cured, at least partially, by informing users how to open a document for editing and save back rather than save a new document with the same name each time, but you still need someone to keep up with the organization.


I guess the point of this post is anytime you have a library, you need a librarian. Without one, the “books” get moved all over the place until it is very hard, if not impossible, to find them.

Peace and Grace,

Twitter: @gbworld