I am currently working on a new solution structure which should enable the best of all worlds with regard to building and debugging the Store Module. I have seen this referenced in several other articles regarding development of C# modules in DNN core, although (provided I get it working) my version will enable the use of the designer, partial classes, etc.

I have written in several other threads regarding the hurdles I ran across as I attempted to get Allan Thompson's web warehouse module running (to be honest, other than conversion to DNN 4, I couldn't see where he did that much else, but he did upgrade the module to .NET 2.0). Specifically, when I attempted to convert the ascx files to use the new codebeside model of .NET 2.0, I ran into a problem where the class for the page would get compiled into both the Module's assembly (I was using WAP for both DNN & the WebControls module) and another app_code_12312.dll in the ASP.NET in the Temporary ASP.NET Files directory. I tried all sorts of workarounds, and finally got a solution that would enable the use of the partial class in compiling and stepping through the module, however, I had to manually delete the codebeside attribute from the page directive to eliminate the error caused by the missing .cs file.

Thus, I have started a new solution, removing the BuildSupport Project, and the C# DotNetNuke WAP, and the WebControls project. I removed all of the Store Module's various provider projects from the DotNetNuke path (they reside in a directory outside of the path, and a post-build event copies the various resources into the directories (this legacy from DNN 3 or 4 or WWStore I don't know who added these, but they work), leaving the Core DotNetNuke.WWStore.WebControls resource and source code files in place, but removing all other source files below it (to prevent double compilation: the ascx files for the tax, address, & shipping providers won't cause compilation errors because they use the codebehind page directive, which doesn't do anything regarding page compilation.).

Next, I deleted the (wwstore) module's DLL's from the DotNetNuke bin directory, opened the DotNetNuke project as a Web Project (not Web application project, also note I had to delete the forum subdirectory from DesktopModules because of compilation error there), and added a reference to all of the Provider Projects (which is where I am right now) and I think I am down to three compilation errors dealing with the providers calling a method from their respective parent control in the WebControls project, which they can no longer (and should never have in the first place) reference since they live in a web project that can't reference the module's WAP (because of double/ambiguous references).

I am going to fix these errors by first removing the reference to the webcontrols project in the provider projects (taxprovider, ShippingProvider &  another provider), then adding a public event (Expanded) to each of these which they can raise when appropriate, and the parent can trap the event and react accordingly. Once this is done, I am hopeful I can convert all of the web user controls in what was the Web Application Project into codebeside, thus finally being able to take full advantage of the Visual Studio.NET 2005 IDE Designers in the module.

-Kenneth S. Courtney