Novinsoft Tech Bulletin 2020 – 02

Previous tech bulletins outlined our phased approach to the development of a new architecture for delivering cross platform applications based on Microsoft .NET. To recap, our target is to support the Windows x86 / ARM, MacOS, iOS and Android platforms with applications that run locally in a disconnected state, like our current Windows x86 desktop applications. We are now ready to roll out this new architecture and begin developing this new class of applications.

State of Microsoft .NET in 2020
The .NET ecosystem has evolved rapidly since Microsoft shifted focus and positioned it as an open source solution for all cross-platform development needs. These are currently the main building blocks for developing .NET applications.

.NET Standard – all platform independent .NET code should target this interface and it would run on all .NET implementations. For our applications this is essentially all business logic (dataset / business rules / calcs / output / APIs) While it’s difficult to express it in terms of code coverage, for an average application it would be about 80% of the codebase.

Further reading:

.NET Standard

.NET Framework – the original .NET implementation, targeting Windows x86 desktop and server applications. Since it is clearly not compatible with the current .NET platform goals it has been deprecated. Version 4.8 will still receive security patches and bugfixes, but no new features are planned. This is the .NET implementation that is used by our existing desktop / web applications and we will continue to support it indefinitely.

.NET Core – For developing web and console applications (basically everything but the UI) for Windows / MacOS / Linux. This is the new core implementation going forward (thus the name). Currently used by the web server portion of our existing web applications, will host all our web applications developed on the new architecture.

Xamarin – For UI and other platform specific tasks targeting MacOS / iOS / Android. Definitely a viable option for delivering on our cross-platform development goals but not the one we favor.

Universal Windows Platform (UWP) – essentially plays the role of Xamarin for targeting the Windows 10 ecosystem. Compelling features but a very limited reach due to its narrow focus.

Blazor – the latest addition to the .NET ecosystem aimed at developing web delivered applications.
Blazor Server is positioned for developing straight web applications, basically an alternative to platforms such as ReactJS / Angular / Vue; Blazor WebAssembly is positioned for developing applications that are delivered via the web but run locally in the browser; this is our preferred approach for delivering cross platform applications expeditiously in a cost effective manner.

Further reading:


Towards the end of the year Microsoft will release the next version of the .NET platform, namely .NET 5. The main takeaway is that .NET is now one platform enabling all development scenarios. The underlying components outlined above will still be there, but will continue to converge and move to the background.

Further reading:

.NET 5

The new Novinsoft application architecture
Over the past year or so we have undergone a root and branch review of our entire codebase and have been rewriting it in its entirety. Every feature and service that it offers has been grouped into one these three buckets:

These are elements that are no longer fit for purpose and a superior replacement is readily available:

  • EZPDF proprietary PDF generator; has been superseded by XML based reports using the XSL-FO publishing standard even in current applications
  • Excel proprietary binary format (XLS) support – this format has been obsolete since 2007 and superseded by the open XML based XLSX, it is astonishing that it has lasted this long.

Core features that are indispensable but needed a thorough refresh to keep up with the times:
  • Our homegrown “Var” data management framework; ground-breaking when it was introduced 25+ years ago and key to our ability to develop large and complex applications quickly and flexibly with small development teams. Completely re-architected to take advantage of the latest offered by the .NET runtime and the C# language.
  • Saved cases – replaced proprietary format derived from the old Windows INI file structure with JSON.
  • Broke up the current monolithic architecture introduced when software meant only Windows desktop applications into a modular set of components that we can mix and match as needed to deliver all types of applications and services that run either locally or remotely (i.e. if the application runs as a service with no UI, all UI related components can be left out of the deployment.
  • All Novinsoft framework modules are now incorporated by applications as NuGet packages instead of being linked into the application allowing much better versioning support. Combined with our new Azure DevOps source management and collaboration platform it will result in a much more flexible approach to working on multiple versions of an application simultaneously (I.e. local / web or production support / new development).

The “if it ain’t broke don’t fix it” category, just a straight port to C# and .NET Standard. These items are mostly calc related.
  • The math library functions (solves, IRR, etc.)
  • Date management (monthiversary, anniversary, age nearest, etc.)
  • Rate tables and TABLE.BIN; recently overhauled with an extensive ecosystem to provide full Ingenium support as well as continuing to work with Excel source material.

Delivering locally running applications with native level performance on all target platforms
As discussed above rewriting the business logic of our application to target .NET Standard will make them available locally in all scenarios; the big decision that must be made is what to do with platform specific code, most notably the UI. Here we’re looking at two main options.
  • Native applications targeting each platform specifically (UWP for Windows 10+ and Xamarin for MacOS / iOS / Android). There are clear advantages to this approach as it offers a best in class experience tailored for each platform. The downsides are (besides the additional development and testing time / cost) that some of these platforms are locked down; iOS especially requires apps to be built using the Apple toolchain on Apple hardware and would have to go through the app store submission process which can be lengthy and sometimes arbitrary. This is not the approach that we prefer, but we will support it on a case by case basis if needed.
  • A web delivered application running in the local browser developed using Blazor WebAssembly. One single application for all target platforms with a similar look and feel. This is our recommended approach so we will delve into it in more detail.

Blazor WebAssembly applications
Delivering full fledged platform independent applications via the browser has always been a goal for developers, but only recently the pieces have fallen into place to make it happen. This is what finally makes it possible for us:
  • Progressive Web Apps (PWA) – A PWA at its most basic is a web application that is “installed” locally. It is in quotes because there is no package that is downloaded and installed; a PWA has a manifest that indicates that an icon should be created on the user’s device which will launch a stripped down browser window (that looks like a native application window) and navigate directly to this web application; in essence a glorified shortcut.
  • Service Worker – for a PWA to deliver tangible benefits, it needs to be able to work offline, or at least provide some level of service. An ideal PWA would be an email client such as Gmail; it has an offline mode that allows the user to browse the already viewed messages, access attachments etc. This is done via a Service Worker that intercepts network requests and caches and makes available the application assets even offline. Unfortunately, our applications are not an email client; the objective is to gather user input and generate calculated values and other output. To do this offline would mean that all application code needed to produce this outcome would have to execute offline, in the browser; until recently this has meant using JavaScript which is simply not an option for complex application with very high performance requirements.
  • WebAssembly – finally, an alternative to JavaScript on the client side. WebAssembly is essentially a virtual machine that executes binary compiled code inside the browser with native performance.
  • Blazor – with Blazor WebAssembly, Microsoft essentially ported the .NET runtime to WebAssembly, which means that basically all .NET code targeting .NET Standard will run in the browser like it does on the server; there are of course downsides.

The main limitation of executing WebAssembly code inside a browser is that (like with JavaScript) it is constrained by the browser security sandbox; this is eminently sensible as it would be massively dangerous to allow untrusted binary code to execute with native privileges. In practice that would mean no ability to launch processes on the client device, no creating arbitrary network connections no access to some OS functions (i.e. Windows registry), very limited access to the file system, etc.

It is also important to point out these limitations have minimal impact on our applications and if needed they can be overcome. One way to do it is run WebAssembly code not inside the browser itself, but inside a browser control hosted by a standard native application; this way it could interoperate with the native application and escape the security sandbox. A plausible scenario would be to take this approach on desktop platforms such as Windows or MacOS and fallback on the browser hosting on mobile platforms which are locked down even to installed applications.

Further reading:

Progressive Web Apps (PWA)

Service Worker


Fine print
  • Everything discussed above only applies to applications developed entirely on the new architecture. Existing applications would need to be completely rewritten with minimal code reuse. Whether it would make business sense to do so would need to be determined on a case by case basis
  • The development environment for new applications is Visual Studio 2019 to start; upgrading to the latest versions of Visual Studio and the .NET ecosystem as they become available and the development schedule permits, is mandatory.

Keep up-to-date on news, events and releases from NOVINSOFT
March 2020
A New Class of Illustrator Applications
August 2019
GWL/London Life/Canada Life Complete Illustration System
September 2018
Our 25th Anniversary
September 2018
Novinsoft Technology Roadmap
July 2018
Par, Par and Not Par
January 2018
Some 2017 highlights
January 2017
Thank Goodness – 2016 is over!
January 2016
Empire Life Web/Mobile Illustration System
September 2014
Recent Client Highlights
April 2014
Tech Meeting
December 2013
Novinsoft goes to Asia
September 2013
Equitable Final Protection
May 2013
20th Anniversary Client Meeting
News archive
See more NovinNews