This will work.

Normally I use the WSP model but I have a special situation where I need to make the LINQ .dbml class visable among multiple projects (because we have multiple developer's) and I need a assembly in the bin directory. With the WSP model a class in te APP_Code folder may not be "compiled in time" so other projects cannot see it's classes.

Anyway I made a WAP project that creates a web.config in it's project. I set debug to "true" in both the DNN Web.config and the web.config in the WAP project.

I set the Linq .dbml class to get it's connection info from the "SiteSqlServer" key.

Make sure you specify that the project will build into the "/bin" directly of the DotNetNuke website.

I call the assembly from a WSP module. When a set a break point in the Linq WAP project my break points are hit.

Now perhaps this works for me because I still make the main module a WSP module.

If you want to see a module that uses this set-up see the DotNetNuke version of http://SilverlightDesktop.net

Lindsay,

first, please be aware, that there are multiple implementations of LINQ, latest is LINQ to Entities (though LINQ2SQL is ... still supported).

In general, Microsoft is focusing on ORM solutions - which would have significant advantages for DNN as well, especially the option to become datastore agnostic. I expect, there will happen a lot within the next year or two...

Unfortunately, this is not a satisfying answer to the question, what to do now :( 

Lindsay - if this is any use ...

I only find I have to store my WAP module project outside DNN if the project targets ASP.NET 3.5 features (like LINQ). It is only then that VS creates a web.config file in the project folder. If the project can just target the 2.0 framework, it can be safely stored in a DesktopModules folder.

Not a useful tip if you want to use VS 2008 for the new features though ....

Off topic Q - is anyone getting email notifications of thread updates on these forums? It seems they were turned off months & months ago and never re-enabled.