I've been reading up on how to develop modules for DNN 4.x. and I went through the Module Development Guide.  When you create the compiled DLLs, does the name of the dll HAVE to be App_Subcode_<module name>.dll?  Maybe it's because I've been developing for DNN 3.x, but it seems like a "weird" way to have your assemblies named for distribution.  Also, I didn't see a SqlDataProvider dll created for the module either, despite setting up my module the way the guide dictated (business layer code in the App_Code folder, web pages in the DesktopModules/<moduleName> folder).

Is this how all 3rd party modules for DNN 4.x have their dlls named?  Can it be changed?  Why is there a .compiled file that accompanies the dll?  Is this a .net 2.0 thing?  Why can't modules I create look more like the DNN core module dlls that get built (i.e. DotNetNuke.Modules.Documents.dll)?

To follow up to Michaels comment, this is more a change surrounding DNN moving to a Web Site model from the traditional VS2003 dll model.  When VS2005 was released it included one format for websites, which caused tremendous backlash from developers so they had to create WAP (Web Application Projects, Michael has a great tutorial on it). 

DNN Core team, being the developers (and rather intelligent marketers) they are and knowing how we all want to play with our shiny new tools on our favorite workbench, released DNN 4.0 the same day VS2005 came out.  It was an exciting day (not for my wife...) They had to make a decision, a) wait and hope to maintain developer support and have the perfect tool for the job or b) sky rocket both products by being available on the same day and deal with it later, or provide meaningful alternatives.  They chose b and it seems to have paid off.  Microsoft released WAP shortly after and made it the standard in VS2005 SP1 and VS2008. 

The module guide that shows the App_SubCode was released the same day (So we all knew how to code our modules for DNN, plus there was this thing called aspnet_merge or something of that sort we could use to compile a group of these granular DLL's into a single assembly.  I think shortly afterwards Michael really took the lead in providing better ways to code modules on his website.  I don't think that documentation has been updated since. 

bah, sorry for the rant. 

Ahhh yes, completly forgot about that point... thanks Michael. 

WAP wasn't available at time of release either. ;)