v7.0: Rename/move projects, update namespaces

2/13/2019 - Marco von Ballmoos (updated on 6/3/2019)

The summary below describes major new features, items of note and breaking changes.

The links above require a login.


  • NuGet Feed: Users can obtain packages via the NuGet feed link given above. Simply add the link as a source, either in Visual Studio or in the solution's NuGet.config file.
  • Source Link: Packages obtained via the NuGet feed include "Source Link", which is integrated with Visual Studio. When you debug into Quino sources, Visual Studio will ask for permission to download symbols and sources and automatically provide seamless debugging.
  • Migration trigger: An application can now control how and when a database change will trigger a schema-migration. It is still highly recommended to use the default behavior, but it is now possible to ignore certain changes on the database side to allow hybrid code-controlled/database-controlled metadata strategies QNO-6170
  • Multi-platform: Includes several bug-fixes for the support for Linux and MacOS that was added in 6.x. The standard CI pipeline is now a Linux image in a Docker container for both Quino-Standard and Quino-WebApi. Quino-Windows uses a Windows container. One of our developers is using JetBrains Rider on a Mac to develop Quino-WebApi.
  • Model-registration: The process for registering a model has been better codified and documented. Applications will still generally call UseModelBuilder<T>, but support for other configurations (ad-hoc/faked models in tests) derives more clearly from there. See Metadata Architecture in the conceptual documentation for more information.
  • Object Graphs: All graph-traversal, formatting and cloning support can now be replaced/configured/extended by products. The GetAllObjects() and GetFormattedGraph() methods for all hierarchical types were hard-coded in previous versions. Now, products inject the appropriate type (e.g. IExpressionGraphTraversalAlgorithm or IExpressionGraphFormattingAlgorithm) and call methods on these objects instead. Additionally, we've created documentation for how a product can implement support its own data hierarchies. See Object Graphs in the conceptual documentation for more information.
  • Web Configuration: We've standardized and documented how to extend ASP.Net applications with Quino. See Web Platform in the conceptual documentation. This configuration will once again change in Quino-WebApi 8.0, where we move to ASP.Net Core and are able to leverage even more of their standard configuration.
  • Command-line Tools: The quino command-line utility that replaced the Quino.Utils package in 6.x has also been extended to support both TeamCity and Azure DevOps. We're using this tool both locally (to update versions and standardize projects) as well as in CI (to set version, update nuspec files for .NET Framework projects and to enable documentation). Both SDK and Framework-style project types are fully supported. We plan to extend the tool further to provide more of the functionality that Quino.Utils used to provide (e.g. updating source headers and fixing myriad project properties). See Tools and, in particular, quino fix in the conceptual documentation for more information on where we are headed.
  • Login Behavior: We've improved the naming in this area to align better with the authentication system. A value of None is no longer supported (there is always a user context) and the default is now UseOperator, which uses (but does not authenticate) as the OS user that executed the software. Single sign-on products would use AuthenticateOperator. See QNO-6147 for more information.
  • Data Cursors and Object Lifetimes: We've improved the event-handling in the data pipeline to avoid inadvertently keeping objects in memory. This was particularly a problem for queries that retrieved a large number of objects. In those cases, even using CreateCursor rather than GetList didn't avoid allocating a ton of memory by the end of the iteration. We detected this when indexing data for Lucene support in a custom product. See QNO-6125 and QNO-5425 for more information.
  • Nullability Annotations: All public APIs in Quino-Standard, Quino-Windows and Quino-WebApi now include [NotNull] and [CanBeNull] annotations for parameters and return types. Many APIs also include [Pure] where appropriate. The annotations are retained and delivered with the NuGet packages, where ReSharper makes use of them in dependent products. See QNO-6092 for more information.
  • Data-driver Debugging: Exceptions in the data driver when using RunMode.Debug now stop in the debugger at the point that they are thrown. Previous versions included a global catch/re-throw handler used to maintain statistics. Errors are now added to statistics in debug mode only if a specific option is set, so that proper debugging behavior has priority, rather than the other way around. See QNO-5723 for more information.
  • Legacy Generated-Code Format: The "V1" generated-code format has been removed. As of Quino 6, all known products using Quino have upgraded to the "V2" format.
  • Web Application Shutdown: We fixed a bug whereby Quino applications weren't being disposed in OWIN applications. This led to dead instances retaining open file handles on log files that the ensuing instance would be unable to open. See QNOWEB-71 for more information.
  • Generic and Metadata Controllers: Both of these controllers include incremental improvements to provide robuster information to generic clients (e.g. the Quino Web Client). We made many improvements to validation, caption and data-retrieval when ramping up to production with several major products based on these technologies.
  • DevExpress Component Upgrade: Quino-Windows now references DevExpress 18.2.5 instead of 15.1.7. DevExpress packages are now available from their own NuGet feed, greatly easing distribution. For backward-compatibility for products that do not wish to pay for a license upgrade, the NuGet feed for Quino-Windows includes pre-release versions of all packages with a version of 7.0.0-devex*. See QNOWIN-243 for more information.

Breaking Changes

The recommended upgrade path is as follows:

  • Use the NuGet Package Manager to update to the released version of Quino 7 (
  • Use the NuGet Package Manager to uninstall any direct references to Encodo.* packages. Make note of which packages you've uninstalled.
  • Install the corresponding Quino.*.Core package for the Encodo.* packages you uninstalled in the step above.
  • If necessary, install the remote-data packages, as described in "Package names" below.
  • Install Quino.Processes if you were using the IProcessManager anywhere.
  • Use Visual Studio's Ctrl + R, G to clean up invalid namespaces.
  • Use Visual Studio's Ctrl + . or ReSharper's Alt + Enter to include the updated namespaces. This may take a while, but is reliable and not complicated.

Runtime targets

All Quino.WebApi and Quino.Windows packages now target .NET Framework 4.7.2. We made this change to improve interoperability with .NET Standard and .NET Core packages, on a recommendation from Microsoft. See QNOWIN-241 for more information.

Package names

We renamed all Encodo.* packages to Quino.Core*. Since this change does not affect high-level packages, most solutions should be largely unaffected. However, if a solution had included one of the Encodo.* assemblies directly, then you need to manually remove that reference and include the Quino.*.Core package instead.

Additionally, we reduced the surface area of Quino.Application.Core (previously named Encodo.Application) by moving significant parts into sub-packages:

  • Quino.Configuration: contains all support for IKeyValueNode<T> nodes and for loading/managing configuration
  • Quino.Feedback: IFeedback and supporting types and methods
  • Quino.CommandLine: all command-line support

Quino.Application.Core still depends on these three packages, but they can now also be used independently of pulling in the full application support.

We also replaced the following packages:

  • Quino.Data.Remoting
  • Quino.Data.Remoting.Json
  • Quino.Server

with the following packages:

  • Quino.Data.Remote.Client
  • Quino.Data.Remote.Server
  • Quino.Protocol.Json
  • Quino.Protocol.Binary.

Clients and servers should instead include the server or client package, respectively and the desired protocol packages. Configure the server with


and the client with



All namespaces now begin with Encodo.Quino. Types that used to begin with just Encodo (no Quino) are now in the Encodo.Quino namespace. For example, Encodo.Core.Bit is known as Encodo.Quino.Core.Bit.


  • IProcessManager is no longer in the Encodo.Application package. It is now in the Quino.Processes package.
  • IEventAggregator is no longer in the Encodo.Core package. It is now in the Quino.Processes package.
  • IPayloadFactory and its associated types are no longer in the Encodo.Connections package (nor is it the renamed Quino.Connections.Core package). Instead, you can find these base types in the Quino.Protocol.Core package.


  • IMetaPropertyPath no longer extends IList<IMetaProperty> and is now immutable. The implementation MetaPropertyPath is also now immutable. Use the GetFirst(), GetFullPath() and ToList() extension methods to get information about the path.

Sign up for our Newsletter