I really think if there was just some way of defining a set of modules within a package where each module points to a different controller that would be a nice way to organize an MVC project within DNN

One thing I am finding really frustrating is the lack of clear terminology. Modules, Desktop modules, module definitions, module controls, packages, these all seem to have subtly different but crucial meanings.

e.g. I am finding that if I upload a [package]  with multiple [component type="Module"] inside it then I end up with a single entry in the Modules table but two entries in the DesktopModules table.

(Edited  because anything in HTML tags seems to get filtered out)

This doesn't work because in the DotNetNuke.Services.Installer.Installers.ModuleInstaller.cs ReadManifest() function it sets the FriendlyName for the DesktopModule to the FriendlyName of the Package; this means two DesktopModules are added with the same FriendlyName, and so when you go to add a module you get a "Key already exists" exception.

Then if you go into the DesktopModule table and manually change the friendlyname to something different you have two desktop modules which share the same project, assemblies, folders, etc, allowing you to add two modules from the same project. I am currently trying to figure out what the heck DesktopModules are about to see if I am doing something crazy, but it appears to work well once I do this absurd hack.

Two things that were tripping me up:

- Don't put multiple module definitions in the tab.. It will kind of work, but you get "Error occured when request service[sic] 'AddModule'" , which the error logs track down to a NullReferenceException in
/API/internalservices/controlbar/AddModule
Message:Object reference not set to an instance of an object.

StackTrace:

at DotNetNuke.Entities.Modules.ModuleController.IsSharedModule(ModuleInfo module) at DotNetNuke.Entities.Tabs.TabChangeTracker.TrackModuleModification(ModuleInfo module, Int32 moduleVersion, Int32 userId) at DotNetNuke.Entities.Modules.ModuleController.UpdateTabModuleOrder(Int32 tabId)

Not sure why this happens, but it seems that if you add two or more definitions for component type="Module" in your .dnn manifest and then make sure you set the FriendlyName in DesktopModules to something different for each DesktopModule you can then finally have two or more modules in the Add modules pane which both reference the same assembly, same folder, same ModuleDefinition, but two DesktopModules.

In an MVC project this means being able to address alternate controllers within the same project via different DesktopModule definitions.

I am also finding the technique of having a "DefaultView" setting for the Module instance, which then redirects from Index() to Whatever() based on this setting, to be a nice way to configure different view for the same ModuleDefinition.


Can anyone tell me if there is a DNN friendly way of altering the FriendlyName for a ModuleDefinition immidiately after installation, or if there is any reason not to use this approach?

Posted By Chris Kuliukas on 03 Jul 2019 11:13 PM

It really seems like because DNN doesn't support MVC routing (kind of important..) you can only build single view modules in MVC, which makes it practically useless. (MVC is a way of organizing a project, a one view / one action MVC is like a one form WinForms/WPF project which can only have an OnLoad and OnUpdate event..)

I can't help with your other questions, but have a read of Andrew Hoefling's DNN MVC Module Routing. My understanding is MVC Routing is supported now.

 

Thanks Olly, I did find it quite strange when I found that the routing seemed to be responding as I expected. Weird that in the documentation this limitation is made very prominent yet it no longer exists.

Assuming you mean the new documentation at DNNDocs.com, I beleive it's still a work in progress, with the community contributing as and when they have time. I'm sure PRs would be welcomed 😀

Okay got it. Do you guys use Evoq by the way? It looks like we're definitely going to be using DNN for our intranet so I want to make sure we contribute back and support the company monetarily, and we have bought a few modules, but is purchasing Evoq the best way to do this and hopefully get some cooperation re: patch submissions?

e.g. I'm now running off a locally compiled 9.3.2 and would like to keep it that way so I can debug and use patches if absolutely necessary, but I would guess that with Evoq you don't get the source code?