It's been posted before about the web app vs web site. I think the general result is "there's no significant advantage" to the change. 

As for making a module for both DNN and general ASP - Possible, of course. A little more difficult though.

My recommendations for this would be (this is very very top of the head)
* Use local variables for any DNN variables (such as UserID, TabID, ect)
* You will have to wrap DNN specific code in compile time conditionals for the "Solution Configurations" corresponding to DNN and nonDNN configurations. As well as create those configurations. (Debug and Release are the defaults in solution configurations) This will allow you to do things like
#if DNN 
    public partial class YOURMODULE : PortalModuleBase, IModuleListener
#elseif ASP
    public partial class YOURMODULE : UserControl
#endif
This will probably need to be done in quite a few places. I doubt this would be effective for more advanced modules - without careful planning.
A good idea might be to create a wrapper for the DNN systems you interact with so you can swap between DNN and you ASP site with only a back end change, and not swapping configurations. I've tried neither of these - it's all top o' the head.
 

I believe that DNN can run modules built in both app or site projects - so use your preference.

Baatezu,

Thanks for suggestions. Your thoughts confirm in fact what I have been doing.

Though I can report only partial success, and it seems that I still have to do some manual coding back/forth between the two cases despite use of the switch DnnIntegrated = true for the DotNetNuke case and DnnIntegrated = false for the regular ASP.net case. That's also because the DotNetNuke project is in web site project and my regular ASP.net work is in web app project. So I have to switch the CodeFile's to CodeBehind's etc etc.

And it's still a general nuisance. In my opinion, DotNetNuke would be greatly, in fact, super super greatly enhanced by modifications to the Core Framework that would allow better interoperability of standard ASP.Net *.ascx controls for use both with DotNetNuke and with regular ASP.Net.

Michael,

So sorry, but I disagree --- development of controls in the DotNetNuke web site project context is far from ideal. It's so much simpler cleaner and easier to do in a regular ASP.Net environment. Once I prove that it's working there, then I port it to the DotNetNuke environment. There's just way too much overhead and everything else in the DotNetNuke environment to complicate and slow down development of a control that ideally can and should be used in a variety of contexts, and NOT solely DotNetNuke.