DNN Blogs

Written for the Community, by the Community

Replacing the Client Dependency Framework

Written By Peter Donker
2025-10-03

For a next minor release (e.g. 10.2) we are planning to move DNN Platform off a project called Client Dependency Framework (CDF in short). We need you to help us test the proposed alternative.

What is the Client Dependency Framework?

The CDF is a library that helps us manage stylesheets (css files) and javascript files in the page output. These are collectively known as Client Resources in our code. I.e. resources that the client (your browser) needs for the application to work. Developers do not include the <script> or <link> tags directly in their work. Instead they will use DNN's API to add resources. Either by calling the ClientResourcesManager, the Javascript class or by using the Webforms controls DnnCssInclude and DnnJsInclude. These items all feed into the CDF. The CDF keeps a list of the added resources, deduplicates (so you don't get multiple jQuery scripts on the page, for instance), prioritizes (so scripts load in the correct order) and then feeds the right <script> and <link> tags into the page output. It also allows you to tell it to bundle and/or minify the scripts in the page output.

Why do we want to move away from the CDF?

DNN has maintained a forked version of the original CDF project for years. But for a long time, now, the original project has become stale. It is officially marked as deprecated on Github and when you follow links to "you should look at this as an alternative" you end up in projects that have themselves died a while ago. This is largely because the development community has moved on and the kind of solution the CDF offers is no longer in demand. Firstly there is the overall decline in demand for Webforms components. Secondly with HTTP/2 now firmly the industry standard, the issue of bundling (allowing the browser to get multiple scripts in a single request) has become more and more a moot point. And finally, developers now typically use transpilation tools when creating their javascript code, which already takes care of minification.

Because the CDF project has been deprecated, we are now wholly responsible for covering any future security holes in this code. And there is quite a bit of code in this library. This places an unwanted strain on the DNN core team. Dragging along code that you don't know well and may have security holes is just not a great feeling.

The move

Instead of trying to bolt in a new third-party solution into the platform, we've decided to replace the CDF with our own code. When bundling and minification are dropped as requirements, we do not need that much code to do what the CDF did. In fact we could make the code more adapted to the future and at the same time greatly simplify it. Over the past weeks I have added this to the platform and rewired our existing code to use this new CDF. The criteria included:

  • Create an injectable class that would do all the work (IClientResourceController)
  • Not rely on webforms (System.Web library)
  • Unify and streamline. I.e. the same patterns for all client resources. The underlying idea is to make it easier to understand for developers what it does.
  • Minimize the dependencies on classes and interfaces. For this reason we chose a fluent API.
  • Make (new) properties of <script> and <link> elements, such as async, defer, etc. available to developers.

Concretely

In the proposed solution you can inject DotNetNuke.Abstractions.ClientResources.IClientResourceController in your code. Then, using DotNetNuke.Web.Client.ResourceManager (new library) you can add a resource as follows:

    this.clientResourcesController
        .CreateScript()
        .FromSrc("~/Resources/Search/Search.js")
        .SetPriority(FileOrder.Js.DefaultPriority)
        .SetProvider(ClientResourceProviders.DnnFormBottomProvider)
        .Register();

There are a lot of extension methods to make adding resources as simple as possible.

Status

Currently the new CDF is a pull request on the main project. Because it is replaces an essential part of DNN, it is a high-risk PR. Therefor we'd love you to try it out. You could help us by trying out the packages posted here:

https://github.com/donker/Dnn.Platform/releases

There is an install and an upgrade package. I need to know if this breaks any of your installations relating to the loading of CSS or JS files. If you're not sure, please install the regular DNN 10.1.1 first, check if your stuff works, and then try to upgrade with the upgrade package. Post any issues in the PR thread here:

https://github.com/dnnsoftware/Dnn.Platform/pull/6729

Thank you.

Total: 10 Comment(s)
This is awesome work Peter! Thank you so much for working towards making this happen, its a great improvement to the platform!
Friday, October 3, 2025 ·
Another modernization step, great :-)
Friday, October 3, 2025 ·
If bundling & minification are dropped: how will it be supported? Because for all the obvious reasons it is important. If you build your own custom theme, you minify it yourself. If you use a theme from a vendor like Mandeeps, EasyDNN or DNN Go, my guess is that it would need minification.
Monday, October 6, 2025 ·
The plans are now to not incorporate minification and bundeling as with HTTP/2 it seems redundant.
Wednesday, October 8, 2025 ·
Minification is commonly done by vendors. But switching on HTTP compression does a similar thing. And Cloudflare also does this. Bundling is commonly done by vendors under their own discretion. But HTTP2 makes this point moot. In any case it is important to realize that this change does not impact these skins or modules functionally. They continue to work as before.
Friday, October 17, 2025 ·
Peter, I testing this with the latest forums release, and didn't encounter any issues.
Wednesday, October 8, 2025 ·
Awesome Peter - thank you for such a great contribution to move DNN Platform forward!
Thursday, October 9, 2025 ·
Thank you Peter!
Monday, November 3, 2025 ·
I am really looking forward to using this in DNN v10.02+, thank you. One odd little note... in the example above under Concretely, should it be 'Resource' (singular) or 'Resources' (plural)? I was assuming it would be `this.clientResourceController`?
Monday, December 8, 2025 ·
I chose for plural as a module can require the framework to emit multiple resources.
Thursday, December 11, 2025 ·

Would you like to help us?

Awesome! Simply post in the forums using the link below and we'll get you started.

Get Involved