Writing Custom DNN Modules: Best Practices from Our Developers

DotNetNuke, now simply known as DNN, has powered Australian intranets and customer portals since the early 2000s, and our team at Aricie still ships custom modules on it for clients across Sydney, Melbourne and Brisbane. Because the platform exposes a stable extension surface, a well-written module can outlive several major version upgrades and stay compatible with skin objects, third-party providers and Razor Web Forms at the same time. This article shares the practical patterns we have refined while helping councils in Perth, retailers in Adelaide and resource companies operating out of the Pilbara keep their sites alive and humming.

The audience we had in mind is the in-house .NET developer who has just been handed a legacy DNN site and needs to extend it, or the agency partner building something new on the platform. We have sprinkled in real examples, anti-patterns to avoid and references to how the local market values solutions that are easy to maintain over the long haul.

Project structure and the DNN layering pattern

Every module we ship follows the same skeleton, which keeps business logic reusable across the legacy Web Forms view, a Razor Web Forms alternative and any future SPA front end. The project contains a business class that inherits from ModuleBase or implements the right controller interface, a DataProvider abstract class and a concrete SqlDataProvider. This mirrors the official DNN tutorials, but we tighten it further by isolating view models and mapping them through AutoMapper so the ASCX control never reaches into the data layer directly.

Naming also matters, especially when several modules live in the same solution. We adopt Company.Module.Feature namespaces, prefix database objects with the module name and keep stored procedures named with the Get, Add, Update, Delete verbs. Australian teams working across time zones from Sydney to Perth quickly appreciate the consistency, because code reviews no longer require guessing which class does what.

Lean on the DNN API rather than reinventing it

One common trap we see in code inherited from offshore vendors is hand-rolled settings tables, ad-hoc permission checks and direct mail sends. DNN already provides ModuleController, TabModuleSettings, ModulePermissionController and Mail.SendEmail, all battle-tested through years of production use. Routing configuration, profile retrieval, role checks, scheduling and even logging through LoggerSource should flow through these APIs rather than through fresh code that bypasses the platform's event pipeline.

Localisation is another area where the built-in helpers shine. By storing resources in .resx files under /App_LocalResources and calling Localization.GetString("Key", LocalResourceFile), the same module will render correctly for a French-speaking branch office in Lyon or an English-speaking team in Melbourne. The framework also handles fall-back cultures transparently, which becomes important when a multinational portal must display prices in AUD while keeping French defaults for European users.

Database access, performance and caching

Our rule of thumb is simple: nothing touches SqlConnection directly inside a user control. All persistence happens through the provider pattern, which makes it possible to swap implementations for Azure SQL, an on-premises PostgreSQL gateway or even a Cosmos backend without touching presentation code. Inside the provider, every query is parameterised, every result set is mapped once into a POCO and every list operation looks for an existing cache key before hitting the database.

For modules that render lists on busy portals, such as property listings or staff directories, we cache output for sixty seconds and offer a CacheTime setting that editors can tweak from the module configuration. CPU-intensive fragments are wrapped with DataCache.SetCache and invalidated explicitly when content changes, rather than relying on cache dependencies that can silently expire. The result is a module that loads quickly on a 4G connection in regional Western Australia and stays responsive during a marketing campaign spike.

Security and lifecycle discipline

Security in custom DNN work is rarely about exotic attacks; it is about being thorough with the basics. Every form posts back through an anti-forgery token, every user input is validated against a whitelist, every render output goes through HtmlUtils.Encode and every file path goes through PathUtils. Permissions are enforced through ModulePermissionController.CanEditModuleContent and friends, never through a custom boolean stored in a module setting. When a module exposes a web API endpoint, we add it to a controller class decorated with [ValidateAntiForgeryToken] and we limit allowed verbs through the DNN routing table.

Lifecycle discipline is the second half of security. Schema versions follow the 04.00.00.SqlDataProvider convention so upgrades run cleanly, and the manifest file declares compatibility with the current major version, the minimum version and the install, upgrade and uninstall scripts. We treat the .dnn manifest as a contract: every dependency, every file, every SQL script is listed, and our release pipeline fails the build if any file in the package folder is not declared. Continuous integration runs unit tests, schema diffs and a smoke test that installs the module in an empty DNN container.

Comparing the lightweight and the enterprise module layout

The two module layouts our Australian clients ask for most often differ as follows, depending on whether the module is a quick utility or a long-lived component.

Aspect	Lightweight module	Enterprise module
Project layout	Single project, business and data in one assembly	Separate business, data and web assemblies
View technology	ASCX Web Forms control	Razor Web Forms plus optional SPA host
Settings storage	Module settings only	Module, tab module and portal settings layered
Localisation	Single language fallback	Full .resx localisation per culture
Caching	Output cache on the control	Provider cache plus output cache
Upgrade path	Manual SQL script sync	Versioned scripts with CI diff
Best fit	Marketing widget on a Sydney SMB site	Multi-tenant portal covering Melbourne, Brisbane and Adelaide

If you are weighing up a custom build for your DNN site, our engineers in France work directly with Australian partners and can pick up an existing codebase, deliver a green-field module or train your in-house team. Reach out to Aricie through the contact form on this site, mention your portal version and the business outcome you have in mind, and we will come back with a proposal that suits your roadmap. No dramas, just a clear plan and a fair dinkum commitment to the long-term health of your platform.