OK... noticed something here.. website is in one large .sln and used the chapter 5 from the book on how to create a module. (Creating a new solution contained within the desktop modules directory) this makes that module ONLY talk to the codebehind files and such WITHIN its own copy of VS. (opening that module solution file) -  (Any changes to the module have to be built there) then the website can run the whole shooting match including the changes to the new module which NOW work as they were built in another running copy of VS. (Hope that was clear) How if possible?? can I take that seperate solution and combine it with the website solution as NOT to keep 2 copies of VS running as it causes a FULL build of the website on EVERY change and its very slow. I think I missed something on the creation of the module but I followed the chap 5 to the T. So suggestions? Is this the way to develop the module before you turn it into a package and then install it the INSTALL way? Something doesnt seem right about that because of all the open VS solutions..

GRIN

FWIW - and this is only my two cents - unless you expect to be selling your module on snowcovered next week - you may be better to begin your exploration of module development using the WSP (Website Project) development model instead using the WAP path.  

WSP modules are dynamically compiled at runtime by asp.net which does mean all the source code as a rule needs to be there are runtime
WAP modules are pre-compiled into a DLL which does mean all your source code does NOT need to be there at runtime.

Since there is no compiling of module or DNN source code involved and you work with a clean DNN install only build there are no application restarts every time you want to test something because asp.net is instead running in dynamic mode compiling pages on the fly as needed.
This allows you to use rapid development style methodologies to test and explore the DNN api without the overheads of continual compile cycles.

Basically whenever you place a new dll into the asp.net bin folder it forces a restart of the entire application.  Using the WAP module whenever you hit build this occurs.  When you are using WSP development process this does not happen since no new dlls are being built and placed in the bin folder - this leads to a faster development cycle.  

And down the track if/when you do decide you want to package up an module for sale and distribution it is really not that difficult a task to take the code you developed under the WSP model and create a WAP (Web Application Project) based module.  Ultimately all the ascx.vb and ascx files remain the same its just how you manage any component elements that change slightly.

There is a very good article on wsp and wap conversions amongst other things here: http://www.codeproject.com/KB/aspnet/...
and here http://www.willstrohl.com/Blog/EntryI....

Both wsp and wap based module function pretty much the same way in DNN for the most part ... there are some exceptions to this rule if you are looking at building providers of any sort which really do need to be based around the WAP model - though having said that - even this is not totally cast in stone.

There are some strong arguments for both methodologies - WAP allow better source control and keeps your source code private - but is much more painful to use in a RAD workflow.  WSP means all your source code is included - but the development cycle is ideal for RAD workflows.

Westa