The summary below describes major new features, items of note and breaking changes. <ul> Resources<ul> <a href="https://encodo.pkgs.visualstudio.com/_packaging/Quino/nuget/v3/index.json">Artifacts</a> (Note: the URL is a NuGet Source; you can't browse here directly) <a href="https://docs.encodo.ch/quino/release/8/">Documentation</a> </ul> Issues/Changelog<ul> <a href="https://secure.encodo.ch/jira/secure/ReleaseNote.jspa?projectId=10006&version=25518">Quino-Standard 8.0.0.2505</a> <a href="https://secure.encodo.ch/jira/secure/ReleaseNote.jspa?projectId=12730&version=25517">Quino-WebAPI 8.0.0.2511</a> <a href="https://secure.encodo.ch/jira/secure/ReleaseNote.jspa?projectId=12731&version=25519">Quino-Windows 8.0.0.69</a> </ul> </ul> <n>The links above require a login.</n> <h>Highlights</h> <ul> Quino-Web now targets ASP.NET Core (<a href="https://secure.encodo.ch/jira/browse/QNOWEB-149">QNOWEB-149</a>, <a href="https://secure.encodo.ch/jira/browse/QNOWEB-84">QNOWEB-84</a>, <a href="https://secure.encodo.ch/jira/browse/QNOWEB-55">QNOWEB-55</a>) Quino-Web has Serilog enabled by default (<a href="https://secure.encodo.ch/jira/browse/QNOWEB-147">QNOWEB-147</a>, <a href="https://secure.encodo.ch/jira/browse/QNOWEB-146">QNOWEB-146</a>, <a href="https://secure.encodo.ch/jira/browse/QNOWEB-145">QNOWEB-145</a>, <a href="https://secure.encodo.ch/jira/browse/QNOWEB-139">QNOWEB-139</a>) Enabled SourceLink for all packages (<a href="https://secure.encodo.ch/jira/browse/QNOWIN-262">QNOWIN-262</a>) Improved testing and debugging support. (<a href="https://secure.encodo.ch/jira/browse/QNO-6289">QNO-6289</a>, <a href="https://secure.encodo.ch/jira/browse/QNO-6282">QNO-6282</a>, <a href="https://secure.encodo.ch/jira/browse/QNO-6278">QNO-6278</a>, <a href="https://secure.encodo.ch/jira/browse/QNO-6277">QNO-6277</a>, <a href="https://secure.encodo.ch/jira/browse/QNO-6275">QNO-6275</a>, <a href="https://secure.encodo.ch/jira/browse/QNO-6255">QNO-6255</a>, <a href="https://secure.encodo.ch/jira/browse/QNO-6213">QNO-6213</a>) Improved culture and language-handling (<a href="https://secure.encodo.ch/jira/browse/QNO-6302">QNO-6302</a>, <a href="https://secure.encodo.ch/jira/browse/QNO-6303">QNO-6303</a>, <a href="https://secure.encodo.ch/jira/browse/QNO-6253">QNO-6253</a>, <a href="https://secure.encodo.ch/jira/browse/QNO-6230">QNO-6230</a>, <a href="https://secure.encodo.ch/jira/browse/QNO-6228">QNO-6228</a>) Extended expression functions with <c>CreateGuid()</c>, <c>CreateDate()</c>, and <c>CreateTime()</c>. (<a href="https://secure.encodo.ch/jira/browse/QNO-6304">QNO-6304</a>, <a href="https://secure.encodo.ch/jira/browse/QNO-6305">QNO-6305</a>) </ul> <h>Breaking Changes</h> Before upgrading, products should make sure that they do not depend on any obsolete members in the current version (7.x). <h level="3">ASP.NET Core</h> Quino-Web 8.0 is a rewrite and is therefore mostly incompatible with 7.x. <ul> The controller returns data in a completely different format The Quino Client has been completely rewritten to accommodate it The startup and pipeline have been completely rewritten to integrate with ASP.NET Core Testing support has been considerably extended to accommodate end-to-end integration testing and in-process hosts </ul> See the <c>Quino-Web/Sandbox.Web</c> project for a working example. This integrates the standard <c>SandboxApplication</c> into a web site using the standard <c>GenericController</c> and <c>MetadataController</c> to provide data and UI to the generic Quino Client. <h level="3">Namespace Changes</h> Some internal types in Quino-Standard have been moved to more appropriate namespaces and assemblies, but the impact on products should be non-existent or very limited. The following types were moved from <c>Encodo.Quino.Core</c> to <c>Encodo.Quino.Culture</c>: <ul> <c>LanguageTextAttribute</c> <c>IValueParser</c> <c>CaptionAttribute</c> <c>LanguageDescriptionAttribute</c> </ul> The following types were moved from <c>Encodo.Quino.Core</c> to <c>Encodo.Quino.TextFormatting</c>: * <c>IFileSizeFormatter</c> <h level="3">Culture- and Language-Handling</h> Quino's default culture-handling has been overhauled. Instead of tracking its own language, Quino now uses the standard .NET <c>CultureInfo.CurrentUICulture</c> for the default language and <c>CultureInfo.CurrentCulture</c> for default formatting (e.g. times, dates, and currencies). Many fields have been marked as obsolete and are no longer used by Quino. <h level="3">Default Languages</h> The default languages in Quino have changed from "en-US" and "de-CH" to "en and "de", respectively. The reasoning behind this is that, while a _requested language_ should be as specific as possible, a _supported language_ should be as general as possible. The standard culture mechanisms and behavior (e.g. .NET Resources) "fall back" to a parent language when a more-specific language cannot be found. If an application claims to only support "en-US", then a request for "en-GB" fails. If the supported language is "en", then any request to a language in the "en" family (e.g. "en-US", "en-GB", "en-AU") will use "en". An application that supports "en-US" and "de-CH" has, therefore, a more limited palette of languages that it can support. <h level="3">Fallback-resolution</h> Quino code runs in the context of a user, who has a list of preferred languages, in decreasing order of preference. This context can last the entire duration of an application (e.g. a standalone application like a console or desktop application) or last as long as a web request. The application itself has a list of languages that it supports, as well as resources and metadata that defines text in these languages. The resources are standard .NET Resources with the standard fallback mechanism (i.e. a request for "en-US" can be satisfied by "en"). The metadata uses <c>DynamicString</c> objects, which encapsulate a map from language codes (e.g. "en" or "de") to strings. During application startup or at the beginning of a web request, the <c>ILanguageResolver</c> determines the language to use for a given set of requested languages. In ASP.NET Core, the requested languages come from the HTTP headers provided by the browser. In standalone applications, the <c>IRequestedLanguageCalculator</c> provides the requested languages. The <c>ILanguageInitializer</c> is responsible for coordinating this during application startup. The rest of Quino uses the following singletons to work with languages. <ul> <c>IDynamicStringFallbackCalculator</c>: Comes into play when a request is made for a language that is not directly supported. For example, if the application supports "en" and "de", then a request for "en-US" will ask this singleton how to resolve the request. <c>IDynamicStringFactory</c>: Creates a dynamic string to describe a given object. The default implementation uses .NET Attributes. <c>ILanguageResolver</c>: Determines the culture to use from a list of available cultures and a list of requested/preferred cultures. <c>IRequestedLanguageCalculator</c>: Provides the sequence of languages from which to choose during initial resolution (web requests _do not_ use this). <c>ILanguageInitializer</c>: Integrates language-selection into the application startup. <c>ICaptionCalculator</c>: Extracts a single caption for a culture from a given object. Appications should use the <c>IDynamicStringFactory</c> in most cases, instead. </ul> An application can control fallback by registering custom <c>IDynamicStringFallbackCalculator</c> and <c>ILanguageResolver</c> implementations (though this is almost certainly not necessary). <h level="3">Opting in or out</h> Any product that calls <c>AddEnglishAndGerman()</c> will automatically be upgraded as well. A product can avoid this change by calling <c>AddAmericanEnglishAndSwissGerman()</c> instead. <h level="4">Reports</h> A product that uses the new languages will have to replace all fields in reports targeted at "en-US" and "de-CH" to target "en" and "de" instead. <h level="4">Database Fields</h> A product that does use the new default languages will have to determine how to migrate database fields created for languages that are no longer explicitly supported. If the model includes value-lists (enums) or multi-language properties , the application will have to migrate the database schema to update multi-language fields (e.g. "caption_en_us" => "caption_en"). <h level="4">Manual MetaIds</h> A product that sets <c>MetaIds</c> manually will migrate without modification (Quino will rename the property in the database). <h level="4">Automatic MetaIds</h> A product that does _not_ set <c>MetaIds</c> (this has been the default in Quino since version 2) will have a MetaID mismatch because the name has changed. By default, Quino will migrate by attempting to drop, then re-create multi-language properties. In the case of value-list captions, this is harmless (since the data stored in these tables are generated wholly from the metadata). For actual multi-language properties with user data in them, this is _a problem_. The simple solution is to call <c>UseLegacyLanguageMappingFinalizerBuilder()</c> during application configuration to ensure a smooth migration (Quino will rename the property in the database). <h level="4">Regenerating Code</h> A product that updates its languages should regenerate code to update any generated language-specific properties. Properties that had previously been generated as, e.g. <c>Caption_en_us</c> will now be <c>Caption_en</c>.