Remove DotNetNuke.Library Circular Dependencies

Description of problem

The core library DotNetNuke.Library utilizes C# Reflection to circumvent a circular dependency problem in the platform. Since DotNetNuke.Library can’t reference another library (such as DotNetNuke.Web.Mvc) that references itself DotNetNuke.Library. There is code scattered throughout the platform that uses C# Reflection which loads the assembly at runtime. While this works it creates side-effects in the platform that are prone to runtime crashes and performance slow-downs.

An example of how we are using reflection in the ModuleControlFactory https://github.com/dnnsoftware/Dnn.Platform/blob/c1a352acb1ae7f52549d1e605822f56ae837ed45/DNN Platform/Library/UI/Modules/ModuleControlFactory.cs#L58-L64

Description of solution

My plan/proposal is to extra shared contracts so the different Module Libraries don’t need to reference the entire DotNetNuke.Library Project. A new project would be created called DotNetNuke.Library.Contracts. All shared interfaces and contracts required for the Module Libraries would be moved to the new DotNetNuke.Library.Contracts project. This would then be referenced by both DotNetNuke.Library and the Module LIbraries. This would then remove the circular dependency and allow us to re-write the code above to

case ".mvc":
    controlFactory = new MvcModuleControlFactory();
    break;

• New Project: DotNetNuke.Library.Contracts
• Module Library: References DotNetNuke.Library.Contracts
• DotNetNuke.Library References: DotNetNuke.Library.Contracts

Reasoning for Change

Creating a contracts project is fundamental to creating the building blocks of a wrapper that removes the dependency on System.Web. After completing this feature we would be able to create a wrapper around System.Web which will be a big step towards a .NET Core migration.

Description of alternatives considered

Leaving things the way they are makes a migration off of System.Web a very large undertaking. By making changes now that create abstractions around System.Web it will make the migration easier to manage in smaller chunks.

Screenshots

N/A

Additional context

N/A

I would like to include this change as part of the Razor Pages Feature. It is not required, but highly recommended. Related: #2599

[mitchelsellers]

At this point, I think that the best recommendation would be to accomplish the following unless any other member of @dnnsoftware/tag has a differing opinion.

• Flag the implementations that exist within DotNetNuke.Library as Obsolete, further note on this below.
• Introduce the new assembly, and duplicate the items that are being moved, into the new namespace
• Update the usage/implementation within the DNN Core

I would suggest this attribute for all removed members.

[Obsolete("This implementation has moved to DotNetNuke.Library.Contracts. Scheduled removal in v11.0.0.")]

Additionally, due to the current deprecation process, I believe that we SHOULD include this in 9.4. My reasoning for this is as follows.

1. This is a major performance improvement. Some initial benchmarking that I prototyped this afternoon shows a reduction of about 15ms per module load when extrapolated across a large installation this is huge.
2. This implementation, although public in the declaration, is really a framework component and shouldn’t be leveraged by external resources.
3. The 9.4.x release line is planned to be the stable release before we remove another batch of Obsolete API’s in 10.x. As such, let us get this performance fix in now.

Additionally, alongside this, I am going to propose a revision to the deprecation policy for internal framework components.

The only question I would ask is regarding the name. Is DotNetNuke.Library.Contracts the proper name? Or should it be more specific such as DotNetNuke.Library.PipelineContracts or otherwise?

[mitchelsellers]

Ah, that’s the missing piece that I didn’t get

DotNetNuke.Library -> DotNetNuke.Contracts DotNetNuke.Library -> DotNetNuke.Web.Mvc DotNetNuke.Web.Mvc -> DotNetNuke.Contracts

Correct?