v2.0-beta1: Configuration, services and web

Published by Marco on

Updated by Marco on

The summary below describes major new features, items of note and breaking changes. The full list of issues is also available for those with access to the Encodo issue tracker.


These are the big ones that forced a major-version change.

Some smaller, but important changes:

  • Added support for RunInTransaction attribute. Specify the attribute on any IMetaTestFixture to wrap a test or every test in a fixture in a transaction. (QNO-4682)
  • Shared connection manager is now disposed when an application is disposed. (QNO-4752)

Breaking changes

Oh yeah. You betcha. This is a major release and we’ve knowingly made a decision not to maintain backwards-compatibility at all costs. Good news, though, the changes to make are relatively straightforward and easy to make if you’ve got a tool like ReSharper that can update using statements automatically.

Namespace changes

As we saw in part I and part II of the guide to using NDepend, Quino 2.0 has unsnarled quite a few dependency issues. A large number of classes and interfaces have been moved out of the Encodo.Tools namespace. Many have been moved to Encodo.Core but others have been scattered into more appropriate and more specific namespaces.

This is one part of the larger changes, easily addressed by using ReSharper to Alt + Enter your way through the compile errors.

Logging changes

Another large change is in renaming IMessageRecorder to IRecorder and IMessageStore to IInMemoryRecorder. Judicious use of search/replace or just a bit of elbow grease will get you through these as well.

Configuration changes

Finally, probably the most far-reaching change is in merging IConfiguration into IApplication. In previous versions of Quino, applications would create a configuration object and pass that to a platform-dependent Quino Run() method. Some configuration was provided by the application and some by the platform-specific method.

The example for Quino 1.13.0 below comes from the JobVortex Winform application.

var configuration = new JobVortexConfiguration
  MainSettings = Settings.Default

configuration.Add(new JobVortexClientConfigurationPackage());

if (!string.IsNullOrEmpty(Settings.Default.DisplayLanguage))
  configuration.DisplayLanguage = new Language(Settings.Default.DisplayLanguage);

  app => new MainForm(app)

In Quino 2.0, the code above has been rewritten as shown below.

using (IMetaApplication application = new JobVortexApplication())
  application.MainSettings = Settings.Default;

  if (!string.IsNullOrEmpty(Settings.Default.DisplayLanguage))
    application.DisplayLanguage = new Language(Settings.Default.DisplayLanguage);

  application.Run(app => new MainForm(app));

As you can see, instead of creating a configuration, the program creates an application object. Instead of using configuration packages mixed with extension methods named “Integrate”, “Configure” and so on, the new API uses “Use” everywhere. This should be comfortable for people familiar with the OWIN/Katana configuration pattern.

It does, however, mean that the IConfiguration, ICoreConfiguration and IMetaConfiguration don’t exist anymore. Instead, use IApplication, ICoreApplication and IMetaApplication Again, a bit of elbow grease will be needed to get through these compile errors, but there’s little to no risk or need for high-level decisions.

There are a lot of these prepackaged methods to help you create common kinds of applications:

  • UseCoreConsole() (a non-Quino application that uses the console)
  • UseMetaConsole() (a Quino application that uses the console)
  • UseCoreWinformDx() (a non-Quino application that uses Winform)
  • UseMetaWinformDx() (a Quino application that uses Winform)
  • UseReporting()
  • UseRemotingServer()
  • Etc.

I think you get the idea. Once we have a final release for Quino 2.0, we’ll write more about how to use this new pattern.

Looking ahead to 2.0 Final

This is still just an internal beta of the 2.0 final version. More changes are on the way, including but not limited to:

  • Remove IConfigurationPackage and standardize the configuration API to be named “Use” everywhere (QNO-4771)
  • GenericObject improvements (QNO-4761, QNO-4762)
  • Change compile location for all projects (QNO-4756)
  • Move a lot of properties from ICoreApplication and IMetaApplication to configuration objects in the service locator. Also improve use of and configuration of service locator (QNO-4659)
  • More improvements to the recorders and logging (QNO-4688)
  • Changes to how ORM objects and metadata are generated. (QNO-4506)
  • Separate Encodo and Quino assemblies into multiple, smaller assemblies (QNO-4376)

See you there!