EntLib vNext Suggestion: Xaml Configuration

Jun 6, 2014 at 8:11 AM
Hello Community,

I am not sure if there are comments/suggestions being taken for the next version of EntLib, but I would like to make one or at least get some discussions around a particular pain point with EntLib as a whole, and that is its configuration mechanism.

First, I do have to say that I appreciate the designer tool that is available with EntLib; it is amazing and worth praise in its own right. However, it is based on a growingly outdated (and not well-liked) technology: .NET Configuration.

I would like to see this designer kept and maintained (or maybe redesigned as a WPF application), but to also see the underlying configuration mechanism for EntLib updated around a much better way of expressing data on .NET platform: by using Xaml.

There are many benefits of using Xaml, namely being able to use markup extensions (a concept that still does not exist in any other serialization mechanism. They are A-W-E-S-O-M-E), and of course the great tooling support in Visual Studio (especially ReSharper). It would be great to see EntLib's configuration to be rebuilt around this technology.

I am proud/happy to say that I currently use Xaml for all my .NET application configuration, and use it for pretty much everything, including my Unity registrations. You can see an example of this here:
https://github.com/DragonSpark/Framework/blob/master/DragonSpark.Application.Server/Configuration/Registrations.xaml

(And yes, this is for an ASP.NET application.)

Obviously, this is the raw object graph. It would be easy enough to dedicate a team to build a designer around this. And, since it's direct object definition/serialization, there is no need for ConfigurationElements, ConfigurationSections, and/or schemas (xsds). It's much simpler and streamlined.

Anyways, I just wanted to get this suggestion out there and possibly a discussion around this. ASP.NET vNext is torching their support for web.config, so I am thinking this is something MSFT as a whole will/should be doing as well... and hopefully doing it the right way. :)

Thank you for any consideration,
Michael
Jul 27, 2014 at 11:48 PM
Yello? Is there a better place I should be posting suggestions? Is this project even alive anymore?
Aug 1, 2014 at 4:28 AM
Yes, this is the right place to post. And thanks for posting to the right place and for your interest!

Firstly, I would recommend creating a workitem to formally capture the idea.

In terms of configuration, the current preferred configuration approach is to use programmatic configuration. That said, there are always use cases for declarative/external configuration. The Silverlight Integration Pack also used a XAML approach for configuration.

Since Enterprise Library was split into separate blocks and released to the community I'm not sure there is a monolithic EntLib vNext. Although, changes to EntLib Common would affect all blocks and would require a relatively large testing effort (compared to changing a single block). In that case, it might make sense to add other changes to the release to leverage the testing.

Actually, the designer tool is already a WPF application.

External XML configuration could still work without a web.config. With EntLib 6 even when using XML configuration the blocks still have to be bootstrapped. It would be a small code change to use a FileConfigurationSource to load an external configuration file instead of the default configuration source.

In general, I'm a bit leery of adding another configuration mechanism. As of now, there are 3 configuration mechanisms:
  1. Standard .NET XML configuration
  2. Fluent configuration API
  3. Programmatic configuration
I'm not sure that adding another declarative configuration mechanism that delivers the same functionality as option 1 is the best use of resources. Were you thinking that the XAML approach would replace the the existing approach? That makes sense to me but we would be breaking a lot of existing code for users wanting to upgrade.

I'm not saying it's a bad idea -- I'm just thinking about the impact. Although if given a choice for a configuration change I would be leaning to simplify by removing some of the existing configuration approaches.

~~
Randy Levy
entlib.support@live.com
Enterprise Library support engineer
Support How-to
Aug 1, 2014 at 9:41 AM
Thank you Randy for your reply. I will create a work item for this for sure.

The advantage of using a Xaml-based configuration over the traditional/current Xml is designer support, not to mention all the power behind Xaml that you do not get in Xml, markup extensions being probably the greatest example.

Using Fluent/programmatic configuration loses the designer support and uses a compiled-resource model. That breaks the idea of configuration here. :) Furthermore, getting back to the designer support notion, by using Xaml, you get tremendous tooling capability out of the box. Not only do you get built-in intellisense (which does not happen in Xml-based configuration, you need to create an .xsd file and then configuration sections and elements... TEDIOUS AND UNNECESSARY), but you get designer support right out of Visual Studio. To see what I mean, open any Xaml file in Visual Studio and select an element in the markup view. As you will see, the Properties Pane comes to life with all of the properties of that element with editors rendered based on the property type, as well as configurations provided on the property type itself.

This is not just UI elements. This is any POCO object defined in Xaml.

This is much like what the EntLib configuration designer application does, but right out of Visual Studio. The case could almost be made to use Visual Studio now and replace the EntLib configuration application altogether, but I will not go that far. :)

As for breaking code and changing, isn't that the nature of software? More notably, there is a palpable shift right now in your company, and this seems to be happening in a lot of places. EntityFramework comes to mind as the best example. They are basically re-writing their entire codebase with the guidance/expectation that if you want the older functionality, stick with 6.x, but if you are building a new application, then using 7.x is recommended as things have changed and your legacy code will no longer work. AspNet vNext is also doing this. I would suggest adopting the same philosophy for EntLib vNext.

In any case, I mentioned this before, but I'll make it a work item now -- if that will even help? -- but EntLib should become part of the .Net Foundation so that enthusiasts like me can easily contribute these sorts of ideas. Based on the activity on this forum, along with the fact it takes approximately two months to get feedback to user suggestions, the community as a whole might stand to benefit from the move. :P

Thanks again for your dialogue,
Michael
Aug 2, 2014 at 12:06 AM
Edited Aug 2, 2014 at 12:07 AM
Thanks for explaining the XAML approach a bit more. It seems my experience with the VS(2010) XAML designer was not as good as yours. ;)

This is much like what the EntLib configuration designer application does, but right out of Visual Studio. The case could almost be made to use Visual Studio now and replace the EntLib configuration application altogether, but I will not go that far. :)

To be honest, I find that more compelling than stacking another configuration mechanism on top. The configuration tool is helpful but I think the need for a configuration tool indicates that the configuration is complicated. Once I have a baseline configuration I usually just edit the XML by hand although I'm not sure how everyone else uses the tool.

This board is (relatively) new and I'm not really sure how many people follow it. It was created when EntLib was split, and released to the community in November 2013. Because each block is it's own entity, I'm not sure there is an EntLib vNext (as a whole). Of course, EntLibCommon does affect all blocks. Community involvement has been a bit less than I was expecting so I do appreciate your interest/enthusiasm. EntLib is accepting community contributions but for larger items/changes it's good (essential!) to discuss and get buy-in before submitting a pull request.
Aug 2, 2014 at 3:30 PM
100% agree. WCF configuration is the same way as well, and the primary complaint that I hear with people trying to use/adopt it. MSFT has made strides with 4.5.x to reduce the friction around configuration.

I'm personally for convention over configuration. However, configuration is still a part of application development, and I would say that the 80-20 rule applies with me personally on all my projects. That is, 80% of the time, convention works fine, but I have probably about 20% of my projects using configuration. Once I caught on to Xaml (and hit the "aha" that it is not just for presentation), I've never looked back... obviously! Because now I'm trying to indoctrinate the world, haha.

FWIW, I've also sat in on a EntLib workshop once on MSFT campus, and I remember hearing all sorts of complaints about .NET configuration. That was the first sign to me that something must be better than what everyone had grown accustomed to using.

Finally, it's surprising that there isn't more activity on this board, since it is the common block and all other blocks depend on it. Anyways, I'll keep a look out on this and submit a work item around this. Thanks again, Randy!