Hi DNN Coder,
The DotNetNukeDataContext, used as a base class for adapted L2S models, contains two constructors that automatically pick up the runtime DotNetNuke connection string. These are prototyped as DotNetNukeDataContext(MappingSource mapping) and DotNetNukeDataContext(MappingSource mapping, IModelAdapter adapter). Your super class will need to call one of these overloads to automatically use the current connection string. If you do not, you will have to manually handle this yourself (by passing your own connection, as it sounds like you are doing).
If you want to construct the base DotNetNukeDataContext yourself, I would recommend passing DotNetNuke.Common.Utilities.Config.GetConnectionString(). This is the value used by the underlying object. However, using one of the constructors that does this for you is the way to go, if at all possible.
Take a look at your designer file and ensure that the empty constructor reads something like:
public MyDataContext() :
base(mappingSource)
{
OnCreated();
}
Unfortunately the designer does not well-support this particular construction method, and may be "helping" by generating the constructor incorrectly. I recall giving serious consideration to this issue, where I had to choose whether to swallow the designer-generated connection string. In the end the purist in me was just too offended to go that route.
I'm not a fan of deploying any code files to an end installation, especially commercial modules. Consider compiling your data model in a separate assembly (or inside your current one) and deploying just that assembly. The LINQ to SQL model adapter has not been extensively tested with the WSP model, and though it will work, I suggest precompilation.
Hope this helps!
Brandon