v1.7.3: Copy/cloning fixes

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.

Highlights

  • More fixes and improvements for the copying/cloning API

Breaking changes

No known breaking changes

v1.7.2: Bug fixes for reporting and UI

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.

Highlights

  • New cloning/data-copying API (performance improvements)
  • Lots of reporting fixes
  • Updates for the Software updater
  • Upgraded to DevExpress 2011.2.9

Breaking changes

No known breaking changes

v1.7.1: Schema import and migration improvements

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.

Highlights

  • SchemaManager API improvements
  • EventAggregator was integrated

Breaking changes

No known breaking changes

v1.7.0.0: Application initialization, configuration, feedback and shutdown rewrite

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.

New Features

Application initialization, configuration, feedback and shutdown rewrite

Generally, a lot of the functionality that used to be Quino-only is now in the Encodo libraries. Any application can now take advantage of:

* startup/shutdown management
* global exception-handling
* feedback
* logging
* software updates
* location manager
* login/authentication/authorization
* language/culture setting
* ApplicationSettingsBase management
* centralized configuration data 

In the feedback area, there is now a method to RequstInput() in addition to ShowMessage() and AskQuestion(). Console output has been improved quite a bit and logging is no longer automatically added to the output (can be re-enabled with --showlog on the command-line or by setting it on ICoreConfiguration.ShowLog). Command-line parameter/command-set setup is greatly improved. Unit tests for core applications are now supported and those for Quino applications are much easier to configure.

  • New configuration file format; makes it much easier to override values in an overlay file
  • Added ConnectionSettingsManager with support for multiple groups of settings
  • Migration UI is now in three components: ChooseDatabaseControl, LoadConfigurationControl and MigratorControl
  • Upgraded to DevExpress 11.2.6
  • Schema migration and import classes are no longer dependent on ADO; all logic is completely independent of external APIs
  • Integrated and updated the software updater
  • Drastically improved and simplified the API for working with Quino applications in unit tests
  • Added support for working with core applications in unit tests
  • Schema migration and import APIs have been drastically improved and simplified

Highlights

  • Database testing classes now use mixins to customizer for different databases; drastically decreases repeated code
  • MetaAccessToolkit now allows override of default access-checker
  • MetaEditPanel.UpdateControls() is now public and refreshes the view for the current EditObject (QNO-2906)
  • Enabled state of a control can now be controlled by aspect (QNO-2882)
  • Renamed a bunch of classes that were still called *Method instead of *Action
  • Support for single sign-on
  • Added StringTools.TryNormalize() to create an identifier from custom rules; changed MetaTools to use this method instead
  • StringTools.AddLeftMargin() no longer leaves a trailing leftMargin (used to do this when there is a trailing newline)
  • LoginForm now manages focus better (depending on whether name is empty)
  • IApplicationToolkit.GetDescription()
    • parts argument now has a default value
    • Accepts an optional argument "rightMargin"
  • Bug fixes for the enhanced incident reporter forms (screenshot names, etc.)
  • Added support for walking the nodes of a DevExpress tree
  • Integrated support for HSV colorspace (makes color and contrast calculation much more intuitive)

Breaking changes

  • Renamed IApplicationContext => IMetaApplication
  • Renamed IApplicationToolkit => IMetaConfiguration
  • Renamed GlobalContextBase => IGlobalContext
  • Renamed GlobalContext.Instance.ApplicationContext.Toolkit => GlobalContext.Instance.Application.Configuration
  • Configuration data file format has changed (see Configuration files for more information)
  • Renamed UnknownEnumValueException => UnexpectedEnumValueException
  • Renamed fields in History module (QNO-2905)
  • Renamed IMetaReadable.Stored => IMetaReadable.Persisted (QNO-2802, QNO-2893)
v1.6.2.5: SQL Server cascade/set-to-null improvements

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.

Highlights

Breaking changes

No known breaking changes

v1.6.2.4: Hotfixes and fixes from bug squashing day

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.

Highlights

  • QNO-3194: Add support to SQL Server driver for GUID primary keys
  • Lots of fixes in many different areas from a "bug-squashing" sprint

Breaking changes

No known breaking changes

v1.6.2.3: Bug fixes for data and UI

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.

Highlights

  • QNO-3198, 2648, QNO-3198: Reporting: support attachments, allow model to control visibility of elements in the reporting tools

Breaking changes

No known breaking changes

ASP.Net MVC 3 auf Mono/Linux

In letzter Zeit hatten wir von der Encodo vermehrt Berührungen mit Mono, da eines der Projekte heterogen mit Windows- und Linux-Hardware (ARM Prozessorarchitektur) operiert. Wir nehmen dies zum Anlass um den aktuellen Stand von Mono zu "protokollieren".

In dem Projekt hat es sowohl C#-Services (Konsolen- und Service-Apps) wie auch Webanwendungen. Eine dieser Webanwendung muss sowohl auf Windows (.Net 4) wie auch auf Open-Embedded-Linux (Mono) laufen.

Da wir für die .Net-Webentwicklung von Microsoft ASP.Net MVC Framework begeistert sind, wollten wir dieses moderne Framework auch auf allen Zielplattformen verwenden können. Am liebsten natürlich die neuste MVC Version 3 (basiert auf .Net 4 und ASP.Net 4) welche auch die neue View-Engine namens "Razor" mit sich bringt. Kurz: das Neuste und coolste was Microsoft in Sachen Webframeworks zu bieten hat.

Mono-Versionen und -Kompatibilität:

An dieser Stelle erst mal ein kleiner Update über die aktuelleren Mono-Versionen aus Sicht der Web-Entwicklung:

Mono 2.6 (Dezember 2009, Standard auf vielen Linux-Distributionen z.B. Ubuntu):

  • C# 3.5
  • Linq
  • ASP.Net 3.5
  • ASP.Net MVC 1 (teilweise)

Mono 2.8 (Oktober 2010, Stable):

  • C# 4
  • ASP.Net 4
  • ASP.Net MVC 1 + 2 (komplett)

Mono 2.10 (Ende 2011):

  • C# 4 + 5 (Experimentell)
  • ASP.Net MVC 3 (teilweise - ohne Razor)

Schnell war klar, dass MVC 1 relativ schnell auf bestehenden Systemen zum Laufen bekommen ist. MVC 2 war etwas anspruchsvoller, da auf dem jeweiligen Linux mindestens Mono 2.8 benötigt wurde, welches bei einigen Herstellern erst in die neusten bzw. kommenden Linux-Versionen einfliesst.

Aber wir wollen ja sowieso lieber MVC 3 mit Razor! Somit ist klar, dass wir uns für die jeweiligen Plattformen eine Mono 2.10 kompilieren mussten (da 2.10 noch nicht offiziell freigegeben ist).

Weitere Informationen zu Mono auf der Mono-Webseite oder in Wikipedia.

Razor:

Aber was ist da mit Razor? Warum ist Razor explizit nicht dabei?

Das Problem mit der View-Engine "Razor" ist, dass Micorosft deren Sourcecode - im Gegensatz zum restlichen MVC - nicht freigegeben hat. Toll! Was nun?

Da die .Net-Assemblies (Binaries, .DLL's) binärkompatibel mit Mono sind, kann man diese grundsätzlich auf "allen" Plattformen ausführen - sofern sie keinen plattformabhängigen Programmcode beinhalten (ähnlich wie z.B. die Java-Packete).

So haben wir folgende Assemblies direkt vom Windows-PC auf das open-embedded Linux-Board in das bin-Verzeichnis der Webanwendung kopiert:

System.Web.Helpers.dll
System.Web.Mvc.dll
System.Web.Razor.dll
System.Web.WebPages.Deployment.dll
System.Web.WebPages.dll
System.Web.WebPages.Razor.dll

Bei den WebPages-Assemblies handelt es ich um den gemeinsamen Code von ASP.Net WebForms und ASP.Net MVC. Dies wurde mit ASP.Net 4 eingeführt.

Den Rest der MVC 3 Webanwendung haben wir als Sourcecode 1:1 von Windows auf das Linux-Board kopiert.

Lizenz-Hinweis: Dieses Kopieren der Razor-Assemblies ist nicht im Sinne von Microsoft. Ob das für das jeweilige Projekt in Frage kommt, muss jeder selbst entscheiden. Es kann zu Lizenzrechtlichen Problemen mit Microsoft führen.

Webserver:

Als Webserver, welche unsere Mono-Anwendung hostet, stehen diverse Optionen zur Verfügung. Wir haben uns mangels Ressourcen auf den Linux-Boards (1GHz CPU, 512 MB Harddisk, 200 MB Memory) für den XSP-Webserver entschieden. Wird mehr Traffic erwartet wäre evtl. ein Webserver wie Apache oder Nginx die bessere Wahl. In unserem Fall wird die Webanwendung aber nur als Web-Admin-GUI von Supportpersonal verwendet.

Der XSP-Webserver ist ein in C# geschriebener OpenSource-Webserver. Pro CLR-Version gibt es ein ausführbares Assembly (XSP2: .Net 2, XSP3: .Net 3.5, XSP4: .Net 4). Dieser Webserver wird im Hauptverzeichnis der Webanwendung gestartet und mit optionalen Parametern (z.B. Portnummer etc.) konfiguriert.

Der Webserver kompiliert dann - wie auch der Casini (DevServer) oder der IIS auf Windows - die Webanwendung on-the-fly. Einziger Unterschied: er merkt nicht, wenn der Sourcecode geändert wird, während er läuft und kompiliert diesen entsprechend erst bei einem Neustart erneut. Damit lässt sich allerdings gut leben.

Mono-Probleme:

Mit diesem Setup lief die Webanwendung welche wir unter Visual Studio 2010 und Casini/IIS entwickelt haben fast auf Anhieb unter Linux. Folgende zwei Probleme mussten noch umgangen werden:

  1. Mono versteht den neuen @:-Syntax nicht. Dieser wird verwendet um nach Bedarf ein automatisches HTML-Encoding zu erhalten. Stattdessen muss der alte Syntax verwendet werden: @= oder @Html.Encode() - je nachdem ob mit oder ohne HTML-Encoding.
  2. Das zweite Problem trat beim Kompilieren der Razor-Views auf. Wir hatten einen Html-Helper welcher optionale (und somit benannte) C#-Parameter verwendete. Dies wurde von Mono innerhalb der Razor-View nicht korrekt erkannt. Anscheinend ist das ein bekannter Mono-Fehler welcher in einer künftigen Mono-Version gefixt wird. Wir haben die optionalen Parameter mit Oldschool überladenen Funtionen (=oveloading) ersetzt.

E voila! Die MVC 3 Razor Webanwendung läuft auf den embedded Linux-Boards und kann unter Windows mit VisualStudio 2010 entwickelt werden!

Kennzahlen:

Da die embedded Linux-Geräte in Sachen Ressourcen nicht mit herkömmlichen PC's mithalten können, interessierte uns der Ressourcenhunger von Mono, XSP und der Webanwendung natürlich brennend. Hier waren wir erneut positiv überrascht.

Der Prozess, welcher die Mono-Runtime, den XSP-Webserver, MVC 3, Razor und unsere Webanwendung hostet ist auf folgende Ressourcen gekommen:

  • Gestartet im Ruhezustand mit gefülltem Output-Cache: 66MB reservierter Speicher wovon 33% effektiv verwendet wurden, 0% CPU
  • Unter Last: 66MB reservierter Speicher wovon 33% effektiv verwendet wurden, 15% CPU

Diese Zahlen sind ohne jegliche Optimierungen und somit mit dem Standard Output-Cache von ASP.Net, den vollen Mono-Libraries etc. Hier könnte noch an einigen Stellen optimiert werden. Auf der Mono-Webseite sind hierzu Dokumentationen verfügbar wie die Mono-Runtime minimiert werden kann.

Wir haben bis jetzt noch nicht weiter optimiert, das diese Kennzahlen für unsere Anwendungen ausreichten. Ob sich das in Zukunft noch ändert wird sich zeigen.

Fazit:

Nachdem die Linux-Experten Mono 2.10 und XSP4 auf den open-embedded Linux-Geräten zum kompilieren gebracht hatten, war die eigentliche Portierung von Windows/.Net auf Linux/Mono erstaunlich unproblematisch und in ca. 1-2 Stunden erledigt. Neben der eigentlichen Webanwendung haben wir auch die eine oder andere Konsolenanwendung 1:1 von Windows auf Linux/Mono kopiert und laufen gelassen - auch das problemlos. Wir waren alle überrascht, wie einfach und schnell das ging und wie gut Mono da out-of-the-box läuft. Wir hatten uns das im Vorfeld aufwendiger und problembehafteter Vorgestellt.

v1.6.2.2: Performance, search and default skin

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.

Highlights

  • Performance improvements
  • Fixed some bugs in display of the search window
  • Set an explicit default skin ("Office 2010 Silver")

Breaking changes

No known breaking changes

v1.6.2.1: Hotfixes (Performance, Reporting, Treeview)

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.

Highlights

Breaking changes

No known breaking changes