Why C# version for DotNetNuke is not (so) important?

Whenever possible, extending frameworks and robust applications should NOT be done by touching the core code and recompilation  but with external, new units of code to be plugged into the framework. The open-closed principle teaches us that application should be opened for extensions but closed for modificationsHow do we extend frameworks correctly?
Extensibility and changes must take place in new classes, (on the other hand, the core code should not be touched).  Because:
1. If you touch the source code, you will have a new version of the framework. Whenever you need to download and upgrade to new version, it will override all your changes. Or break the logic of your new code. Maintenance and upgrades will become strenuous efforts.
2. Seperating extensions (e.g. some specific chat module) from the core (DNN core services) increases an application robustness: The core acts as service which is being developed by one team and has well-known signature and responsibilites. All custom extensions are in lower trust-boundaries, they do not affect the application kernel, they are not mixed-up into the application but act as client who consume the application services.
3. You are not the developer of the code you want to change, you are not even team member. You are not aware of the consequences and implications of your change. Any code you change might change behavior of other components and create bugs you won’t be aware of.

What can we do inside DNN without touching the source code?
The right way to look at DNN, is as compiled framework , IL code (byte code),a black box,  that was programmed with some unknown programming language (Why would you care? it’s a compiled IL .NET code) , that can be extended using  various techniques – Following is a list of extensions and tunings one mught apply to DNN without touching the source code:
1. If you want to add functionality to some web page, (for example, to allow your visitors to chat together) –  buy/download /develop DNN module and plug it into the system. Modules can be developed in any .Net language, includes C#.

2. If you want to change the look & feel of your pages (for example, adding new left panel to your pages)  –  create/buy/download  DNN skin (upgrades do not affect skins) and plug it into the system.

3. If you want to embed in your skin some dynamic data, such as presenting  the security role of the logged in user, create/buy/download skin object.

4. If you want to change some internal behavior of the system, (for example, make all the modules and DNN core to log messages to Windows event viewer) – Create new provider (read here about the provider model) and plug it into the system (or buy one).

5. Some behavioral properties of the system are defined in configuration files (for example, to allow the user to reset her password , simply change the configuration key: enablePasswordReset)

6. If you are unhappy with some texts and translations in your portal, download/create language pack.

7. If you are facing bugs which you have reason to believe come from DNN core – report in the DNN bug tracking system.

8. If you are lacking some important feature – suggest your feature here.

You can see for yourself, extending DNN might be done in many ways, none of them involves touching the source code. You can extend DNN with any .NET language you prefer. Changing the source code is your last resort.

© 2021 Yoni Goldberg. All rights reserved.