Oqtane Blog

Since the inception of the project, Oqtane has always tried to stay true to its overarching philosophy which is primarily focused on speed and performance. The Oqtane 2.2 release continues with this trend by receiving some notable improvements in the user interface area.

Hot on the heels of Microsoft BUILD 2021 we are pleased to announce the official release of Oqtane 2.1, a new major release of the popular modular application framework for Blazor, adding multi-database support to its growing list of framework capabilities.

Oqtane has been receiving plenty of exposure in recent months and was featured on the .NET Community Standup with Safia Abdalla and Jon Galloway on April 13. The 2.0.2 release contains a variety of user experience improvements for both software developers and end users.

Since releasing version 2.0 in coordination with the .NET 5 launch event at .NET Conf, Oqtane has continued to mature and gain momentum. As expected, broader adoption has revealed opportunities for improvement and led to more user feedback on how to enhance the framework to improve its resiliency and cater to additional use cases.

Strategically timed with the release of .NET Conf 2020 and .NET 5... we are pleased to announce the official release of Oqtane 2.0, an open source Modular Application Framework for Blazor.

It is recommended that you upgrade Oqtane on a regular basis in order to ensure you are running the latest framework version. Running the latest version provides you with the latest fixes and features, and also helps protect your installation from security vulnerabilities. As a result it is our goal to make the upgrade process as automated and streamlined as possible.

It is possible to install Oqtane without using Visual Studio. However in order to do this you need to become familiar with the specifics of hosting a Blazor application. In this article we will install an Oqtane release locally on a Windows 10 machine using IIS.

Since releasing Oqtane 1.0 at Microsoft BUILD 2020, the response by the .NET community has been tremendous. We attribute this phenomenon partly to the excitement around Blazor WebAssembly and partly to the fact that Oqtane offers a unique value proposition for modular software development which has really struck a chord with developers worldwide. In the past month there has been a total of 57 pull requests submitted by 8 different contributors, pushing the total number of project commits over 1000, and sowing the seeds for a passionate project ecosystem.

Strategically timed with Microsoft BUILD 2020 and the release of .NET Core 3.2... we are pleased to announce the official 1.0 release of Oqtane, an open source Modular Application Framework for Blazor.

In previous blog posts I have said that Oqtane was "heavily influenced and inspired" by DNN. I realize this statement is rather vague so I thought it may be helpful to provide a bit more detail in order to help clarify the similarities and differences.

Most products are created with some core principles in mind. These principles provide a central theme for all major product decisions. The theme behind DNN was extensibility, and as a result almost every core feature was developed in a manner which could be enhanced, extended or overridden. The theme for Oqtane also includes extensibility but places a much greater emphasis on "speed", which is highlighted by the Oqtane brand name whose root word "octane" is a standard measure of the performance of engine fuel. Speed is a general attribute and for a framework like Oqtane it needs to encompass a wide variety of characteristics such as the speed of installation, familiarization, development, deployment, and interaction with the product.

The question of Oqtane vs DNN has come up numerous times in recent months. In general it seems that people are trying to understand the rationale behind creating a completely new open source project as opposed to evolving the existing DNN project. In order to answer this question it is helpful to step back in time and review the events which got us to where we are today.

Uploading files is a very common requirement in most web applications however Blazor does not currently have a native file upload component. Steve Sanderson blogged about this a few weeks ago and even posted a sample project on Github. Oqtane has a need to upload module and theme packages for installation at run-time so we had also implemented our own solution some time ago - which I was happy to discover closely aligned with the approach suggested above.

Regardless of the deployment approach, Blazor leverages a common component model for developing applications. In theory this offers a high level of flexibility and reusability as it allows you to develop a single codebase which can then be deployed in multiple ways. The ability to write once and run anywhere is a very desirable capability if you want your application to be available in as many forms as possible ( ie. web, mobile, desktop ). This capability is also especially helpful at the present time to workaround some of the limitations in the client-side development model. Specifically it allows you to develop a client-side application using the more productive server-side development approach ( which offers full debugging support in Visual Studio 2019 or VS Code ) and focus your efforts solely on testing your application in the client-side model.

It was an honor being a guest on the show again after an 8 year hiatus... Richard Campbell and Carl Franklin continue to provide the creative insight and passion which makes .NET Rocks! the premiere podcast for Microsoft .NET developers worldwide. This episode focused on Blazor and Oqtane.

Based on the hierarchical model in Blazor, it is trivial to call a method in a parent component from within a child component. But what if you want to do the opposite? A use case for this type of scenario might be a data entry form where a variety of different sections are rendered as child components; however, there might only be a single Submit button for the form which is inside the parent component. So when a user clicks Submit the application may want to call a method in each child component to perform validation or even save the information to a database. Let's explore a few different options to accomplish our goal.

Those of us who have been closely following the evolution of Blazor over the past year have been eagerly awaiting some official guidance from Microsoft in regards to application security. This was finally delivered in the .NET Core 3 Preview 6 release in June where they included some new components, examples, and docmentation related to implementing authentication and authorization in Blazor applications.

Blazor components can accept parameters that are used to pass information from a parent component to a child component. This is a powerful feature however in a real-world application such as Oqtane where you may have many layers of nested components, it can be quite cumbersome and verbose if you need to pass a parameter value explicitly through all of the hierarchical layers. Cascading parameters solve this problem by providing a convenient way for an ancestor component to provide a value that is then available to all descendent components.

This past week I had the opportunity to do presentations about Blazor and Oqtane at a number of community events both locally and internationally. This required me to update my slide deck from the DNN Summit to include the latest information from Microsoft about Blazor, including clarification of the client vs. server hosting models, release schedule, and more technical details about how the technology works under the covers. And now that Oqtane has been officially released as an open source project, it also allowed me to include some information about why I created the project, the technical goals of the original proof of concept, and the reception by the .NET community.

In the vast majority of cases when you are using Blazor you will never need to worry about assembly loading. However in a modular framework like Oqtane, where you need to be able to create independent components which are loaded dynamically at run-time, assembly loading becomes a critical requirement. And although this blog is primarily focused on Blazor, there are some fundamental aspects of assembly management in .NET Core which needs to be explained as there are obviously some dependencies in common.

Blazor applications are based on components. A component is an element of UI that handles user events and defines flexible UI rendering logic. One the most significant benefits of components is that they promote a high level of code reusability. Under the covers, components are .NET classes written in the form of a Razor markup page with a .razor file extension. Razor is a syntax for combining HTML markup with C# code designed for developer productivity. Razor components are compiled into .NET assemblies that can be shared and distributed as Nuget packages. At run-time components render into an in-memory representation of the browser DOM called a "render tree" that is used to update the UI in a flexible and efficient way.

Routing is essentially the "brain" of a web application. In a traditional ASP.NET MVC application, routing is the process of directing an HTTP request to a controller which is running on the server so that it can serve up content to a client browser. In contrast, in a single-page application (SPA), the router responds to navigation actions directly in the client browser without making a request to the server to fetch new content. In both cases, routers utilize route templates which are basically patterns that describe the locations to match in order to trigger a specific rendering.

Oqtane was originally conceived as a proof of concept to determine if Blazor would be capable of supporting a modular application framework. Taking inspiration from DotNetNuke, it utilizes many concepts from this pionering open source .NET CMS. Specifically it supports multi-tenancy, a fully dynamic page compositing model, designer friendly skins, extensibility via third party modules, and a familiar data model. That being said this was not a migration project; Oqtane was built from the ground up using modern .NET Core patterns and technology.