Oh, and I've also added the following to the C# class and csproj.  

<code>using Microsoft.Extensions.DependencyInjection;</code>

<code><Reference Include="netstandard" /></code>

I just found a core theme object that's doing almost exactly what I'm doing, but I don't see any differences.  🤔 

https://github.com/dnnsof...User.ascx.cs#L11-L35

I still can't get the <code>DependencyProvider</code> to resolve, even when using <code>Globals.</code>.

WebForms DI support will be available in DNN 10, which will support regular constructor injection without having to do any other tricks.

<code>Globals.DependencyProvider</code> is internal, so that's why the core skin object can use it but your skin object cannot.

Until DNN 10, you can use the following technique to get the DI scope for the request:

<code>
using DotNetNuke.Abstractions;
using DotNetNuke.Common.Extensions;

private readonly INavigationManager _NavigationManager;

public User()
{
    IServiceScope currentScope = HttpContext.Current.GetScope();
    IServiceProvider serviceProvider = scope.ServiceProvider;
    this._NavigationManager = serviceProvider.GetRequiredService<INavigationManager>();  
}
</code>

Posted By Brian Dukes on 1/14/2025 1:36 PM

Until DNN 10, you can use the following technique to get the DI scope for the request:

<code>
using DotNetNuke.Abstractions;
using DotNetNuke.Common.Extensions;

private readonly INavigationManager _NavigationManager;

public User()
{
    IServiceScope currentScope = HttpContext.Current.GetScope();
    IServiceProvider serviceProvider = scope.ServiceProvider;
    this._NavigationManager = serviceProvider.GetRequiredService<INavigationManager>();  
}
</code>

This was exactly what I needed... Thanks, Brian!  🥳💪🏽

 

To expand on Brian's excellent trick here (I have done this in many places). You can prepare for the future by having both the parameterless contructor and the one with dependency injection and then the parameterless one you can make it call the "new" one and mark it obsolete or add a todo comment to remove it later.

Okay, so here we are a year later. v10 has been out for a while. I am interested in using the code versions of the new fluent CDF stuff in my skin. I don't want to use the skin objects because we generate a few different JS files sometimes and not others. So our auth.bundle.esm.js may or may not be there. So we like to wrap it in a utility/helper that calls System.IO.File.Exists().

So, I've added a partial to my theme and am including partials/preheader-cdf.ascx. My environment is DNN v10.02.01 and I really wanted to do the DI the new way. I did find the right interface, IClientResourceController. But no matter how many examples I found or things I read that seemed to be hinting that there was a new way in v10... I could not get it to work. 

Here is what I do have working:

<%@ Import Namespace="Microsoft.Extensions.DependencyInjection" %>
<%@ Import Namespace="DotNetNuke.Common.Extensions" %>
<%@ Import Namespace="DotNetNuke.Abstractions" %>
<%@ Import Namespace="DotNetNuke.Abstractions.ClientResources" %>
<%@ Import Namespace="DotNetNuke.Web.Client.ResourceManager" %>

<script runat="server">

  private IClientResourceController _clientResourceController;

  protected override void OnLoad(EventArgs e)
  {
      base.OnLoad(e);
      AddJs();
      // AddOpenGraph();
  }

  private void AddJs()
  {
    // TODO get the v10 way working, this also works in v9
    IServiceScope currentScope = HttpContext.Current.GetScope();
    IServiceProvider serviceProvider = currentScope.ServiceProvider;
    this._clientResourceController = serviceProvider.GetRequiredService(); 

    // TESTING Fluent CDF
    var cssAuth = _clientResourceController.CreateStylesheet("SkinAuth.css", PathNameAlias.SkinPath)
      .SetProvider(ClientResourceProviders.DnnFormBottomProvider)
      .SetPriority(FileOrder.Css.SkinCss)
    ;
    _clientResourceController.AddStylesheet(cssAuth);
    ...

So, anyone know what the DNN v10 way to do those first 3 lines under the // TODO?

I don't think there's a way to use constructor injection from an .ascx file. You need to be able to create a new constructor, but you can't do that in an .ascx file because you don't know the class name. You have to do it from a codebehind .cs file that the .ascx file inherits from.

So, for your workflow, Jeremy, I think what you have is probably the best you can do.

If I wired up the code behind, is there an example somewhere of what that would look like?

The example I posted above should work for a codebehind (introduce a constructor and add arguments for each item you'd like to pull from the DI container)