With the DNN Core we do have individual trees for each Module. The Survey module is WSP format and it sits in it's own tree in Source Control.

I guess the difference is we don't check the DotNetNuke site into source control only the module. If you check the entire DotNetNuke site into Source control then the WSP modules would have to sit in the main project.

Here is an interesting twist (at least for me).  On my production site I have gotten rid of another WAP module and replaced it with an updated WSP version of the module.  Let's call this module ModuleA.  However, a couple of other custom modules of mine (currently WAP) on that same portal were compiled with references to the .dll of ModuleA which I just replaced with a WSP version.  As such, there is no longer a ModuleA .dll in the bin folder and the other modules are now throwing an error.  The error is a version error, however, so I think it's just because they need to be recompiled against the new version of ModuleA and not because it has a problem finding the new WSP module.

So am I correct that if I make a ModuleA .dll from my current WSP version and then use that ModuleA .dll in the reference of my other custom module, compile the other custom modules against it, and then deploy those modules on my portal they will work just fine with the WSP version even though there won't be a ModuleA .dll on my portal?