All,

I did some research on my question above and came up with the following solution that seems to work for me pretty well.

Overall, the general concept here is...

(1) Create the baseline control using the DotNetNuke Module Creator.

(2) Open the ASCX-based control in Visual Studio and develop as usual.

(3) Avoid or isolate DotNetNuke dependencies and use the ASCX anywhere.

Here are the details.

...............................................................................
HOW_TO_CREATE_A_CUSTOM_MODULE__BEGIN

As of 2017-04-14, here is 1 way to add a new custom ASCX-based Module in DotNetNuke "8.0.3" and develop in Visual Studio.

Note that throughout this site, "MyModules.sln", and throughout the root site, "DotNetNuke.sln", everywhere in config files it should always be set as (targetFramework="4.6.1") and in Visual Studio > Property Pages, > Build, we also should have "4.6.1" there too.

Go to the target DotNetNuke site.

Login as an admin.

Add a test page to the site, or use an existing test page.

Go to the test page.

Note that it seems that using the DotNetNuke site itself here is necessary for DotNetNuke to easily be able to "see" and use the new Module, though there may be another way via Visual Studio.

Switch to Edit Page mode.

At the top of the page, choose > Modules, > Create Module.

The "Module Creator" will appear in the DotNetNuke Module tray at the top of the screen.

Click-Hold-And-Drag the "Module Creator" onto the test page.

That will show the "Module Creator" form.

On the form, the "Owner Name" should be the same for all your custom Modules, such a "MyModules" here.

Note, the "Owner Name" you choose should NOT contain spaces, and should only contain the characters a-z, A-Z, underscore, and 0-9.

Note, that "MyModules" will be a folder created in the file system on the server, such as "C:\inetpub\wwwroot\dotnetnuke\DesktopModules\MyModules\" for example.

The "MyModules" folder will contain a set of child-folders, and each child-folder will contain a custom Module.

On the form, The "Module Name" should identify the particular control clearly, but also be kind of short (under 16 characters), and it will be used when searching-for and placing your Module on a page.

Note, the "Module Name" you choose should NOT contain spaces, and should only contain the characters a-z, A-Z, underscore, and 0-9.

Note, the "Module Name" will be used for a folder name for this Module, such as "C:\inetpub\wwwroot\dotnetnuke\DesktopModules\MyModules\MyModuleV01\" for example.

Note, if you are creating a new version of an existing custom Module, then the "Module Name" should have a version-specifier suffix, such as "V01" or "V02" or etc.

On the form, "Language" should be "C#" here.

On the form, "Template" should be "Module - User Control" here.

On the form, the "Control Name" is required.

Note, the "Control Name" you choose should NOT contain spaces, and should only contain the characters a-z, A-Z, underscore, and 0-9.

Note, the "Control Name" will such as "C:\inetpub\wwwroot\dotnetnuke\DesktopModules\MyModules\MyModuleV01\MyControlV01.ascx" for example.

Note, to help enforce simplicity and clarity and generality, put just 1 ASCX in 1 Module folder.

On the form, click the "Create Module" button.

Use RDC (or similar) to go to the server where DotNetNuke is hosted, unless you already have a "MyModules.sln" file.

For one-time setup, go to the Visual Studio and choose > File, > Open, > Web Site, and open the "MyModules" folder, unless you already have a "MyModules.sln" file.

For one-time setup, save the Solution file as "C:\inetpub\wwwroot\MyModules.sln" on the server.

For one time setup, add the references to this project's bin folder, per the Reference information below.

You need to "exclude" the RESX file in the Module's App_LocalResources folder or change its contents, as noted below in the ResxFormat section below.

Comment out any "dnn" code on the ASCX page, such as...

... %@ Register TagPrefix="dnn" TagName="Label" Src="~/controls/LabelControl.ascx" % ...

... dnn:label id="plField" runat="server" text="Field" helptext="Enter a value" controlname="txtField" ...

...because we are making the ASCX-based module to be used easily in either in a DotNet site or in a DotNetNuke site.

In the ASCX CodeBehind file, the ".cs" file, comment out the following boilerplate sample, if it exits...

//txtField.Text = (string)Settings["field"];

//ModuleController.Instance.UpdateModuleSetting(ModuleId, "field", txtField.Text);

//DotNetNuke.UI.Skins.Skin.AddModuleMessage(this, "Update Successful", DotNetNuke.UI.Skins.Controls.ModuleMessage.ModuleMessageType.GreenSuccess);

...because we are making the ASCX-based module to be used easily used in either in a DotNet site or in a DotNetNuke site, and this is just boilerplate code.

Edit the ASCX and its code-behind file as desired.

Compile.

Search for the Module on the DotNetNuke site, search for the Module, place the Module on the page as usual.

On the "ASCX.cs" file, do NOT comment-out or remove the following using statement...

using DotNetNuke.Entities.Modules;

...or any other DotNetNuke or Dnn using statements, but it can be switched to work just in a plain DotNet site later if desired.

You should be able to avoid having to RDC or work on the web server by simply mapping a drive to the server on your local workstation and then locally opening the Solution file there.

When changing References in the project, it is probably safer to do that when working on the web server itself, via RDC or direct, as the References should point to the root DotNetNuke site's bin folder.

Develop as normal in Visual Studio, locally.

HOW_TO_CREATE_A_CUSTOM_MODULE__END


...............................................................................
HOW_TO_TEST_OUTSIDE_OF_DOTNETNUKE__BEGIN

If you want to test the Module outside for DotNetNuke then do the following.

Add an ASPX page to the "MyModules.sln" at the root.

Drag the ASCX onto the page.

Comment the Register directive on the ASCX, if it exists.

Register the ASCX in "web.config" in the root of "MyModules.sln", like the others there, per comments and examples in the "web.config" file.

Develop and test as you wish.

See details elsewhere to setup the control.

Note, to run outside of DotNetNuke, for testing to be run outside of DotNetNuke, one must use the following...

public partial class MyModuleV01ControlV01 : System.Web.UI.UserControl

Note, to run outside of DotNetNuke, for testing to be run inside DotNetNuke, one must use the following...

public partial class MyModuleV01ControlV01 : DotNetNuke.Entities.Modules.PortalModuleBase

Note, to run inside of DotNetNuke, for testing to be run inside DotNetNuke, one must use the following...

public partial class MyModuleV01ControlV01 : DotNetNuke.Entities.Modules.PortalModuleBase

HOW_TO_TEST_OUTSIDE_OF_DOTNETNUKE__END


...............................................................................
HOW_TO_USE_A_PARTIAL_PAGE_REFRESH__BEGIN

If you want to use partial-page refreshing then do the following.

Add an ASPX page to the "MyModules.sln" at the root.

Drag the ASCX onto the page.

Comment the Register directive, if it exists, and Register it in "web.config" in the root of "MyModules.sln", like the others there, per comments and examples in the "web.config" file.

On the ASPX, if try to create a test page outside of DotNetNuke, then put the following right after the <form> tag on the ASPX page...



<asp:ScriptManager ID="ScriptManager1" runat="server" EnablePageMethods="true" EnablePartialRendering="true"></asp:ScriptManager>

...to use AJAX partial-page refreshes.

Note, you should NOT add the to the ASCX page at all, it must be in the Non-DotNeNuke page.

Note, you do NOT need to add the anywhere when running the ASCX inside DotNetNuke, because a ScriptManager is guaranteed in each DotNetNuke hosting page.

To the ASCX add the following...



PUT ALL YOUR PARTIAL-PAGE REFESH CONTENT HERE.







PUT ALL YOUR PARTIAL-PAGE REFESH CONTENT HERE.





...to create a region that will use partial-page refreshes.

Develop and test as you wish.

HOW_TO_USE_A_PARTIAL_PAGE_REFRESH__END


...............................................................................
REFERENCES_LIST__BEGIN

As of 2017-06-14, this is the full set of References required, which contains the minimum set of DotNetNuke-based References.

Note, DotNetNuke-based References generally (but not always) start with "Dnn" or "DotNetNuke".

Note, some DotNetNuke-based References, References upon which DotNetNuke relies, do NOT being with "Dnn" or "DotNetNuke", for example "PetaPoco" and the like.

Note, to run inside of DotNetNuke, one needs the DotNetNuke-based References, which is the current setup for "MyModules.sln" as of 2017-06-14.

Note, to run outside of DotNetNuke, one needs to remove the DotNetNuke-based references.

Note, the ".refresh" files are necessary and ensure the ".dll" file is pulled from the root site, "C:\inetpub\wwwroot\dotnetnuke\bin\", which is exactly what we want.

As of 2017-06-14, here are the Referencs.

C:\inetpub\wwwroot\dotnetnuke\DesktopModules\MyModules\Bin>dir
Volume in drive C is OSDisk
Volume Serial Number is 9274-1B97

Directory of C:\inetpub\wwwroot\dotnetnuke\DesktopModules\MyModules\Bin

06/14/2017 06:04 AM .
06/14/2017 06:04 AM ..
05/26/2016 01:01 PM 146,944 ClientDependency.Core.dll
06/08/2017 01:12 PM 72 ClientDependency.Core.dll.refresh
05/26/2016 01:01 PM 22,528 CountryListBox.dll
06/08/2017 01:12 PM 58 CountryListBox.dll.refresh
05/26/2016 01:02 PM 2,730,496 DotNetNuke.dll
05/31/2017 08:28 AM 50 DotNetNuke.dll.refresh
05/26/2016 01:01 PM 16,384 DotNetNuke.Instrumentation.dll
05/31/2017 08:28 AM 82 DotNetNuke.Instrumentation.dll.refresh
05/26/2016 01:01 PM 236,544 dotnetnuke.log4net.dll
05/31/2017 08:28 AM 66 DotNetNuke.Log4Net.dll.refresh
05/26/2016 01:01 PM 31,232 DotNetNuke.Services.Syndication.dll
05/31/2017 08:29 AM 92 DotNetNuke.Services.Syndication.dll.refresh
05/26/2016 01:01 PM 36,352 DotNetNuke.Web.Client.dll
05/31/2017 08:29 AM 72 DotNetNuke.Web.Client.dll.refresh
05/26/2016 12:59 PM 283,648 DotNetNuke.WebControls.dll
05/31/2017 08:29 AM 74 DotNetNuke.WebControls.dll.refresh
05/26/2016 01:01 PM 493,056 DotNetNuke.WebUtility.dll
05/31/2017 08:29 AM 72 DotNetNuke.WebUtility.dll.refresh
05/26/2016 12:59 PM 27,136 Lucene.Net.Contrib.FastVectorHighlighter.dll
06/08/2017 01:14 PM 110 Lucene.Net.Contrib.FastVectorHighlighter.dll.refresh
05/26/2016 12:59 PM 753,664 Lucene.Net.dll
06/08/2017 01:14 PM 50 Lucene.Net.dll.refresh
04/03/2010 11:55 AM 563,040 Microsoft.AnalysisServices.AdomdClient.dll
06/08/2017 01:14 PM 106 Microsoft.AnalysisServices.AdomdClient.dll.refresh
05/26/2016 12:59 PM 24,064 Microsoft.ApplicationBlocks.Data.dll
06/08/2017 01:14 PM 94 Microsoft.ApplicationBlocks.Data.dll.refresh
05/26/2016 12:59 PM 29,344 Microsoft.CodeDom.Providers.DotNetCompilerPlatform.dll
06/08/2017 01:14 PM 130 Microsoft.CodeDom.Providers.DotNetCompilerPlatform.dll.refresh
05/26/2016 01:01 PM 100,048 Microsoft.Web.Helpers.dll
06/08/2017 01:14 PM 72 Microsoft.Web.Helpers.dll.refresh
05/26/2016 01:00 PM 45,416 Microsoft.Web.Infrastructure.dll
06/08/2017 01:14 PM 86 Microsoft.Web.Infrastructure.dll.refresh
05/26/2016 01:00 PM 520,192 Newtonsoft.Json.dll
06/08/2017 01:14 PM 60 Newtonsoft.Json.dll.refresh
05/26/2016 12:59 PM 66,560 PetaPoco.dll
06/08/2017 01:14 PM 46 PetaPoco.dll.refresh
05/26/2016 01:00 PM 249,344 SchwabenCode.QuickIO.dll
06/08/2017 01:14 PM 70 SchwabenCode.QuickIO.dll.refresh
05/26/2016 12:59 PM 122,880 SharpZipLib.dll
06/08/2017 01:14 PM 52 SharpZipLib.dll.refresh
05/26/2016 01:00 PM 185,544 System.Net.Http.Formatting.dll
06/08/2017 01:14 PM 82 System.Net.Http.Formatting.dll.refresh
05/26/2016 01:00 PM 139,984 System.Web.Helpers.dll
06/08/2017 01:14 PM 66 System.Web.Helpers.dll.refresh
05/26/2016 01:00 PM 471,240 System.Web.Http.dll
06/08/2017 01:14 PM 60 System.Web.Http.dll.refresh
05/26/2016 01:00 PM 82,120 System.Web.Http.WebHost.dll
06/08/2017 01:14 PM 76 System.Web.Http.WebHost.dll.refresh
05/26/2016 01:01 PM 554,704 System.Web.Mvc.dll
06/08/2017 01:14 PM 58 System.Web.Mvc.dll.refresh
05/26/2016 01:00 PM 271,056 System.Web.Razor.dll
06/08/2017 01:14 PM 62 System.Web.Razor.dll.refresh
05/26/2016 01:00 PM 41,680 System.Web.WebPages.Deployment.dll
06/08/2017 01:14 PM 90 System.Web.WebPages.Deployment.dll.refresh
05/26/2016 01:00 PM 211,664 System.Web.WebPages.dll
06/08/2017 01:14 PM 68 System.Web.WebPages.dll.refresh
05/26/2016 01:00 PM 39,632 System.Web.WebPages.Razor.dll
06/08/2017 01:14 PM 80 System.Web.WebPages.Razor.dll.refresh
05/26/2016 12:59 PM 19,453,952 Telerik.Web.UI.dll
06/08/2017 01:14 PM 58 Telerik.Web.UI.dll.refresh
05/26/2016 01:00 PM 74,752 WebFormsMvp.dll
06/08/2017 01:14 PM 52 WebFormsMvp.dll.refresh
05/26/2016 01:01 PM 38,608 WebMatrix.Data.dll
06/08/2017 01:14 PM 58 WebMatrix.Data.dll.refresh
05/26/2016 01:01 PM 76,496 WebMatrix.WebData.dll
06/08/2017 01:14 PM 64 WebMatrix.WebData.dll.refresh
66 File(s) 28,142,692 bytes
2 Dir(s) 13,423,972,352 bytes free

C:\inetpub\wwwroot\dotnetnuke\DesktopModules\MyModules\Bin

REFERENCES_LIST__BEGIN

...............................................................................
RESX_FIX__BEGIN

As of 2017-06-14, the ".resx" that is produced when creating a new custom Module with the Module Creator is not valid and it shows and error when browsed in Visual Studio.

This is probably due to the fact tha t the Module Creator

The error is as follows...

ResX input is not valid. Cannot find valid resheader tags for the ResX reader and writer type names

Th the ResX file that is created for the control in the App_LocalResources file.

To fix that error, one has use the right ResX format, to make the file look like a resx that gets created for a new DotNet project, so just create a new DotNet project and use its resx.

RESX_FIX__BEGIN


Note, as with any such technical writing, writing this out in Plain English may make it seem more difficult than it really is. That is the nature of language and the brain. For example, try to write out the steps to do something "simple" like "how to tie you shoe" and it will, usually, look more complicated than it really is.

HTH.

Thanks.

-- Mark Kamoski

As someone who was unfortunate enough to inherit projects where people attempted to do the same thing, let me dissuade you with this. The inherent problem with your design proclamation is that .NET is by definition, a page based architecture. Unless you reject aspx-based files all together and roll your own mini-DNN module serving architecture (which seems redundant). It will be a design compromise and a GUARANTEED maintenance nightmare if you implement this. I've seen at least 4-5 attempts and all have been abject failures. Which only gives DNN an unfair reputation as 'junk' technology in a client's eyes, and either way makes the job of the NEXT person much harder.

IMO< you should commit to a framework that has a successful track record, and integrate it with similar frameworks (like ReactJS or Angular, or node.js, etc) that are also proven successful. If you continue this design, don't say I didn't warn ya!