There has been lot said recently about the pros and cons of WAP vs inner site module developement prcoess.
I think there is more or less of a consensus to regard WAP as better for granularity and source control, while missing the essential feature of Edit and Continue.
While having the module compile to its own assembly and the module's code contained in its single directory seem sensible advantages, having to rebuild any single modification thus to support a subsequent DNN restart can be quite frustrating and time consuming.
An alternative solution has been proposed to include some kind of DNN stub in order to support E&C, but it still requires some manipulation and has the disadvantage that the stub app does not reproduce all of the DNN environement state.
Well, I must first say I'm afraid I don't have an ultimate solution to that issue, nor have I seen any around without its load of limitations.
Still I think I have something interesting to propose, which many will find interesting.
I found out that you can set up some kind of an hybrid solution from an initial WAP module, that enables partial Edit and Continue: Here's the process and corresponding results:
- In VS.Net, setup/open a regular WAP module project
- In your Portal module base ascx files, replace the "CodeBehind" directive attribute by a "CodeFile" attribute
- In the property tab of the correspondiong code behind files, set the Compile mode from "Compile" to "None"
- Rebuild your project
Now you can Edit and continue the codebehind files such as in the in site module developement process.
What happens is that when peforming the operations quoted above, you brought your portal module base control to some kind of nicely ambiguous state:
- In Visual Studio, the control belongs to your project just as before, it sees the rest of the components and controls that the project has, you have regular intellisense, no change
- In IIS, they do not belong to the module's assembly anymore, but to the running DNN app instead, with corresponding dynamic compilation and Edit and continue activated.
This can be a huge time saver when you debug your controls, and you can easily revert to regular compiled codebehind mode whenever you're ready for packaging, though you don't have to.
Of course you're still left with rebuilding business layer classes and the inner user controls, but I think that's still a step forward and also:
- you may be able to temporarily bring some controllers into the codebehind as inner classes/methods if you prepare for heavy debugging, thus need Edit and Continue
- I have recently released a keep alive module (free with source code) which automatically pings thus restarts the app, at recycle time: this will instantly restart DNN on every module build, so that may be a few seconds saved each time during debug session. See the corresponding anouncement thread.
Finally, I think we've got something interesting with that hybrid solution, and I'd be interested to learn if some of you find ways to extend the scope of the code that you can easily swap between inner assembly wap compilation and dynamic DNN compilation.
Maybe we could find a way to add some inner app_code directory to the module that integrates at runtime into the main app (BuildManager tweaking?), so that one can easily move a class file and subsequent dependant classes to that new folder, set their compile mode to false for a debug session, and bring them back into the assembly at packaging time.
Cheers