This is concerning the advantages & disadvantages of storing the VS project for a DNN module in the DesktopModules/Module folder of your dev site, or completely outside the site.

I have seen a number of tutorials recommending the former, and I used to do this, but hit a problem in my latest project which uses LINQ to SQL. By the way I am using VWD 2008 SP1, and the project is a WAP project in C#.

In VWD 2008 when you create a new WAP project, a web.config file is automatically created in your project folder. I used to find I could delete this, however it seems essential for LINQ to work. If I remove it, all LINQ controls (such as asp:LinqDataSource) become unrecognised, and the .dbml designer stops working.

However, if I leave the web.config file alone, the DNN site cannot run. It throws some error (something about virtual directories not being configured as applications - whatever it is it indicates that you have more than 1 web.config in the application).

So the only solution seems to move the project outside the website. The incovenience of this is that I have to copy files into the site to test after each build. I also can't seem to get debugging to work. I have configured the project per Charles Nurse's guide, but when I attempt to save the Web settings I am always prompted to create a virtual directory.

So, do you know of any way I can move the project back into the DesktopModules/Module folder and have it work, or how to get debugging working with it outside the website?

Many thanks.

You need to delete the web.config file that VS adds and modify the DNN web.config manually or you could use MIchael Washington's tool.

www.adefwebserver.com/DotNetNukeHELP/Misc/LinqPrep/

Or move to DNN 5.0 .Net3.5 which I belive can take care of that for you.

I must admit that I have never developed with this sort of project structure; my data mediation almost always resides in a separate assembly.  I also don't believe that I've ever once used a LinqDataSource.

That said, I wonder if you might be able to work around this issue with a post-build action (or msbuild modification) that removes/renames the web.config.  Also, it would be useful to determine exactly what in your web.config is needed in your environment; many times you can declaratively specify these values directly in an ASCX control (such as registering the Linq presentation assembly).  

Finally, you might consider a workaround where you create a separate class library in a subdirectory of your module, thereby avoiding many of these issues.

Just a few ideas I thought you might want to explore -- hope they help!

Brandon