Quino’s Roadmap to .NET Standard and .NET Core
Published by marco on
Note: this article was originally published at Encodo.com in May, 2018.
With Quino 5, we’ve gotten to a pretty good place organizationally. Dependencies are well-separated into projects—and there are almost 150 of them.
We can use code-coverage, solution-wide-analysis and so on without a problem. TeamCity runs the ~10,000 tests quickly enough to provide feedback in a reasonable time. The tests run even more quickly on our desktops. It’s a pretty comfortable and efficient experience, overall.
Monolithic Solution: Pros and Cons
As of Quino 5, all Quino-related code was still in one repository and included in a single solution file. Luckily for us, Visual Studio 2017 (and Rider and Visual Studio for Mac) were able to keep up quite well with such a large solution. Recent improvements to performance kept the experience quite comfortable on a reasonably equipped developer machine.
Having everything in one place is both an advantage and disadvantage: when we make adjustments to low-level shared code, the refactoring is applied in all dependent components, automatically. If it’s not 100% automatic, at least we know where we need to make changes in dependent components. This provides immediate feedback on any API changes, letting us fine-tune and adjust until the API is appropriate for known use cases.
On the other hand, having everything in one place means that you must make sure that your API not only works for but compiles and tests against components that you may not immediately be interested in.
For example, we’ve been pushing much harder on the web front lately. Changes we make in the web components (or in the underlying Quino core) must also work immediately for dependent Winform and WPF components. Otherwise, the solution doesn’t compile and tests fail.
While this setup had its benefits, the drawbacks were becoming more painful. We wanted to be able to work on one platform without worrying about all of the others.
On top of that, all code in one place is no longer possible with cross-platform support. Some code—Winform and WPF—doesn’t run on Mac or Linux.
The time had come to separate Quino into a few larger repositories.
We decided to split along platform-specific lines.
- Quino-Standard: all common code, including base libraries, application, configuration and IOC support, metadata, builders and all data drivers
- Quino-WebApi: all web-related code, including remaining ASP.NET MVC support
- Quino-Windows: all Windows-platform-only code (Windows-only APIs (i.e. native code) as well as Winform and WPF)
The Quino-WebApi and Quino-Windows solution will consume Quino-Standard via NuGet packages, just like any other Quino-based product. And, just like any Quino-based product, they will be able to choose when to upgrade to a newer version of Quino-Standard.
Part of the motivation for the split is cross-platform support. The goal is to target all assemblies in Quino-Standard to .NET Standard 2.0. The large core of Quino will be available on all platforms supported by .NET Core 2.0 and higher.
This work is quite far along and we expect to complete it by August 2018.
As of Quino 5.0.5, we’ve moved web-based code to its own repository and set up a parallel deployment for it. Currently, the assemblies still target .NET Framework, but the goal here is to target class libraries to .NET Standard and to use .NET Core for all tests and sample web projects.
We expect to complete this work by August 2018 as well.
We will be moving all Winform and WPF code to its own repository, setting it up with its own deployment (as we did with Quino-WebApi). These projects will remain targeted to .NET Framework 4.6.2 (the lowest version that supports interop with .NET Standard assemblies).
We expect this work to be completed by July 2018.
One goal we have with this change is to be able to use Quino code from Xamarin projects. Any support we build for mobile projects will proceed in a separate repository from the very beginning.
We’ll keep you posted on work and improvements and news in this area.
Customer will, for the most part, not notice this change, except in minor version numbers. Core and platform versions may (and almost certainly will) diverge between major versions. For major versions, we plan to ship all platforms with a single version number.