znPlugin update -- discussion on hubFS

I've initiated two discussions at hubFS (Post 3806 and Post 3786) on some aspects on znPlugin. Specifically, the parts that relate to performing efficient type comparisons and casting. There are a lot of ideas in that thread, including some sample code. Post #3875 is particularly significant, as it is responsible for the latest changes in the framework.

The discussions have slowed somewhat, but they are still good reads for people interested in Reflection within F#.

znPlugin -- generic plug-in library

As I mentioned earlier, znPlugin is a generic plug-in library that allows developers to add such functionality to their applications / libraries without forcing them to conform to any pre-defined interfaces.

Some competing libraries / frameworks are listed below:
  • MSINC .NET Plugins Library - A library, written in 2004, that does exactly what I am trying to do. I've been going through the documentation, and it provides some great ideas of how to reach my goal.
  • MSDN article - Food for thought on what needs to be taken into account when writing a robust library.
  • TechRepublic - Use C# and the .NET Framework to develop your own plugin architecture
  • Creating a Flexible Dynamic Plugin Architecture under .NET - They use XML files to store plugin information independent of the actual assembly. I did not opt for this approach, as it is extremely cumbersome to maintain an independent file unnecessarily.
  • Task Plug-in: A Flexible .NET Plug-in Architecture - A good introduction to elementary plug-in architectures.

I have already finished this library, for the most part. The only things left are to wrap the unsafe sections in try / catch blocks, perform testing and write some more documentation.

znOptions / znConfig update

Well, it's been a while since I've posted. First, some changes:
  • znOptions has been renamed to znConfig.
  • The library has been redesigned to support more than one options style platform.
  • Instead of hard-coding the save formats, I will use a plug-in architecture (more on this later).
Second, I have found some additional resources that have provided additional inspiration and ideas:
  • Nini - As per the description, "Nini is an uncommonly powerful .NET configuration library designed to help build highly configurable applications quickly." Though I haven't used this library, reading the documentation seems to hold this up.
  • libconfig - The description states, "Libconfig is a simple library for manipulating structured configuration files, like this one: test.cfg. This file format is more compact and more readable than XML. And unlike XML, it is type-aware, so it is not necessary to do string parsing in application code." The type-aware part is interesting, though I've no intention of looking at the source code so I will be coming up with a solution for that independently.
  • Elektra - Specifically, the backend page gave me some ideas about databases.
I was half-done with znConfig when I came across Nini. Looking at the documentation, I realized that it was what I wanted to implement when I came up with the idea in the first place. As such, I also remembered another library that I was supposed to implement first: znPlugin, a generic plug-in library.

As such, development on znConfig has temporarily ceased until znPlugin is done. Please see the next post for more information about znPlugin.

NOTE: In case there is any question, I am not reading/downloading/studying/... any source code from any of the libraries mentioned in my posts (save for the MSDN reference code). The whole point here is to learn about F# through implementation ("learn by doing", and all that).