Sorry for not responding. I finally got this working this week. I am now able to store my .NET 3.5 WAP module project in DesktopModules (i.e. in the module's install folder) and debug it using VS 2008 or VWD 2008 Express. Here's my procedure (I am sure you don't need most of this, but just for completeness). I think the step I was missing was #6 below.:

Preparation: Install the LinqPrep module (Michael Washington's tool www.adefwebserver.com/DotNetNukeHELP/Misc/LinqPrep/). This is a must for LINQ projects, but seems to also put a lot of .NET 3.5 critical settings into the website's web.config file.

1. Create the module's Install Folder inside the DesktopModules folder in the local website.

2. Copy the complete source code for the module into the folder. This includes all the files normally installed in a module installation (e.g. the .ascx, .resx files, images etc) plus the VB/C# code files. Organise the files into the same subfolders you would expect them to live in in a module installation (e.g. \App_LocalResources, \images etc).

3. Open the module project in VS 2008 or VWD 2008 Express

4. Open the References folder and check that none of the references are highlighted as invalid.
Note: I put all referenced assemblies in a Bin subfolder (e.g. DotNetNuke.dll, DotNetNuke.WebControls.dll, 3rd party assemblies etc) of the module folder (not the local website’s Bin folder). This allows me to compile the module against a "minimum supported version" of DNN which might be an earlier version than whatever version my local website is running.

For each reference to a DotNetNuke assembly that you copied to the Bin folder from an earlier version of DotNetNuke, open the reference’s properties and change the Copy Local property to False. This will stop these assemblies from getting copied into the website’s Bin folder when the project is built (which would cause the website to crash if it was running a later version of DotNetNuke).

5. Open the project’s properties and on the Build tab, for each Configuration option (Release and Debug), set the Output Path to: ..\..\Bin\
This will ensure that when you build the project, the module assembly is saved to the website’s Bin folder.

6. If VS has created a web.config file inside the project, compare the entries with the website's web.config. My guess about the source of this is that it is created if the Visual Studio project has not been told to use the website’s web.config file (see Override application root below), or if the website’s web.config file does not have the required entries in it for .NET 3.5 and any special code you are using. The LinqPrep tool sets up all the required entries for LINQ but I have found I have had to sometimes copy extra entries into the website’s web.config file (e.g. when using the MS ReportViewer control). I am not an expert here so can't explain more sorry. If the website and the project are configured correctly, try deleting the extra web.config file – hopefully Visual Studio will not recreate it.

7. On Web tab, enter the following:
a. Start Action: Start URL, and set this to the URL of your website (e.g. http://localhost/dnn4)
b. Servers: Use Local IIS Web Server, and enter Project URL as the website’s URL followed by /DesktopModules/ followed by the Module Install Folder
e.g. http://localhost/dnn4/DesktopModules/ModuleName
c. Select Override application root URL, and set this to the URL of your website (e.g. http://localhost/dnn4)

These settings allow you to debug the module using the Visual Studio debugger. This step was taken straight from Charles Nurse's guide, but for some reason was not working for me until I got the website's web.config set up right.

8. Check that you can build the project. This should produce the module’s assembly in the local website’s Bin folder (not in the Bin folder in the Module Install Folder).

Debugging

The module can be debugged using the Visual Studio debugger as follows:

1. Open the local website’s web.config file and check that in the <compilation> element, debug is set to “true”, e.g. <compilation debug="true" strict="false">. Note that for optimal performance, this must be “false” for live websites, so only change to “true” for development websites.

2. Click Build > Configuration Manager and set the Active Solution Configuration to Debug

3. Set a breakpoint in your code where you want to start debugging

4. Click Debug > Start debugging. A new browser window will open and display the website home page.

5. Navigate to the page where the module is placed. When you trigger the code to run where the breakpoint is placed, the website page will pause and you can switch to Visual Studio and debug the code using the usual Visual Studio debugging functions.

Note: in case of problems, check the Build settings and the Web settings against the settings specified above.

Hope this helps.

Thanks for the acknowledgement. Its not really original work - I put this together from other guides, plus a bit of my own tweaking. Other guides are:

http://weblogs.asp.net/ianrobinson/archive/2008/10/15/creating-dotnetnuke-modules-using-a-web-application-project-wap.aspx

http://www.apptheory.com/dotnetnuke/dotnetnuke_blogs/articletype/articleview/articleid/202/best_practices_development_team_collaboration_and_dotnetnuke_part_3_the_references_amp_project_structure.aspx

http://www.dotnetnuke.com/Community/Blogs/tabid/825/EntryId/1650/DotNetNuke-Web-Application-Projects-and-Visual-Studio-2008.aspx

http://adefwebserver.com/DotNetNukeHELP/DNN4_WAP/

FYI, I just edited my post and added an important point about the Copy Local property of assembly references. If you use my approach of putting the assemblies of a "minimum supported version" of DNN in the module's local Bin folder, then set Copy Local to False to avoid crashing the site when you build the project.