How to create a "library" module (no UI i.e. razor components)?

[lanthonyneville]

In the DNN world there is an extension type called "library". This is for cases where no UI is needed - e.g. it installs functionality that is shared by other regular modules, or installs server-based functionality like scheduled tasks.

I tried making a module with a single project containing the usual components:

• a class implementing IModule
• a class implementing MigratableModuleBase, IInstallable
• a class implementing IClientStartup (does nothing)
• a class implementing IServerStartup
• no Razor components & nothing inheriting ModuleBase

... however it was not recognised as a module when uploaded and Oqtane restarted (no entry under Admin Dashboard > Module Management). The assembly is present in the website, so I can reference it in other modules (as a shared dependency) ... I would just like to see it recognised so I can see what version is installed.

Is there a similar concept in Oqtane and how do I achieve it?

Thanks

[vnetonline]

Can you share your IModuleInfo ?

[lanthonyneville]

I meant IModule. Here it is anyway:

    public class ModuleInfo : IModule
    {
        public ModuleDefinition ModuleDefinition => new ModuleDefinition
        {
            Name = "Acme Dependencies Module",
            Description = "Acme Dependencies Module (container for shared & 3rd party DLLs)",
            Version = "1.0.0",
            Owner = "Acme Ltd",
            Categories = "Acme Ltd",
            ServerManagerType = "Acme.DependenciesModule.ModuleManager, Acme.DependenciesModule.Oqtane",
            ReleaseVersions = "1.0.0",
            Dependencies = ""
        };
    }

[mdmontesinos]

I also tried to achieve that and I ended up creating an empty Index.razor with a message like "NOT INTENDED TO USE. ONLY INTERNAL" and set the Categories property of the ModuleDefinition to "Admin" so that it doesn't show up for content managers when adding modules to a page.

[lanthonyneville]

Thanks - good idea

[leigh-pointer]

@lanthonyneville currently there is now way to achieve this. The way @mdmontesinos is the way that I have created the install package for the Oqtane Templates.
However things could have or will change seening that Oqtane can now run Headless. Maybe @sbwalker can add a bit more light?

[sbwalker]

Oqtane has always been able to run "headless" because it is a client/server application. Headless simply means that the default Blazor UI cannot be launched in a browser (however the backend is still running on a server). The terminology was changed in 5.x from render mode "None" to "Headless" for clarity. An example of when to specify Headless is in an environment where you are running desktop MAUI clients and do not want the web UI to be available. Or perhaps you have created another independent web application and you just want to interact with the Oqtane API (ie. via JwT tokens) - but not utilize the Oqtane UI.

Note that Oqtane ueses a "code as configuration" approach rather than a file-based approach (ie. manifest.json) which means that there is a dependency between the framework and .NET - as only .NET assemblies can be inspected using reflection.

[sbwalker]

@lanthonyneville currently an Oqtane "module" needs to have at least one razor component which implements IModuleControl (ie. via ModuleBase). This is because Oqtane modules are not required to have a ModuleInfo.cs class and because modules are discovered using reflection at startup (ie. the framework inspects assemblies for classes implementing IModuleControl). So the approach suggested by @mdmontesinos is the recommended approach for this scenario - simply include a razor component (or a class which implements IModuleControl).

[sbwalker]

@lanthonyneville #4197 adds support for Library modules (ie. without UI components). You just need to include a ModuleInfo class with a unique namespace.

[lanthonyneville]

Wow! Thanks @sbwalker . Now I am thinking more about what I can do with "library" modules, it seems the right place to implement a public Web API, i.e. not for consumption by a client module UI, but external clients.

Would it be better to categorise these as "headless" rather than "library" modules, to be more consistent with the existing terminology you mentioned above ?

[leigh-pointer]

@lanthonyneville #4197 adds support for Library modules (ie. without UI components). You just need to include a ModuleInfo class with a unique namespace.

Do we need a template?

[sbwalker]

@leigh-pointer I was not planning on including a template in the framework for this... but you could create a custom template to include with your Studio-Elf CodeBehindTemplates.

[sbwalker]

@lanthonyneville I usually include my Public API in my standard module project as its easier to develop, test, and deploy when all aspects are in the same solution rather than physically splitting them into multiple projects/assemblies (plus fewer assemblies is better for performance). However, you should do whatever makes sense for you.

In regards to the naming convention, my only concern is that "Headless" in the context of a Site render mode, means something totally different than a "Headless" module. Could this cause confusion? The Headless render more is a run-time configuration setting which disables the Web UI for the framework. A Headless module is a software development concept allowing the framework to recognize a module with no UI components.