Jowen Mei's Blog

I noticed that the dbml file stores the connection string in a Settings file, stored in the same project.
I use multiple projects to separate the entities from the ui, so this is unwanted behavior. I want it to read the connection string from the app.config.

This can be easily achieved:

• Go to the Connection properties of your dataContext
• Set the Connection string to None
• Set Application Setting to False

This will prevent the generator to create a default constructor. This makes it possible to add your own, which will read the connection string from the config file.

public YourDataContext()
   : base(ConfigurationManager.ConnectionStrings["connString"].ConnectionString, mappingSource)
{
}

Thanks go to David Klein

For the first time I’m experimenting with Linq-to-Sql (L2S).
Microsoft targets L2S for the simpler scenario’s/architectures (if that scares you, just let me say that stackoverflow.com is running on L2S!).
Because of this, a Detach() method is not supported. For these kind of scenario’s, Microsoft wants developers to use the Entity Framework.

One could argue if you should even use Detach() in the first place.
Here’s a nice discussion between Rick Strahl and Ian Cooper, where the latter suggests you should be sending messages across boundaries, not objects.
Steve Michelotti suggests to exclude reference data from your context.
I agree with the fact that you should be aware of what is contained in the dataContext. It’s not a garbage can, keep it small. The datacontext represents a unit of work.
However, I think this is not a complete solution. It’s not transparant, and doesn’t work every time.

In my search for a generic Detach() method, I came across this post of Jonas Stawski. It’s a generic solution with excellent performance.

You only have to add this base class method:

public void Detach()
{
   GetType().GetMethod("Initialize", BindingFlags.Instance | BindingFlags.NonPublic).Invoke(this, null);
}

The method uses reflection to call the Initialize() method, which will reset all the assocation properties. It can now be added to another dataContext, which will not try to save the assocation properties.

Jonas comes with a huge warning that the OnCreated() method is called after Initialize(), which could lead to unwanted behavior. I fixed this problem modifying the T4 template from which the entities are generated.

Normally, the Initialize() method is only included if you have turned on serialization. (By setting the Serialization Mode to Unidirectional). I modified the template so that it always generates these Initialize() methods.

#region Construction
public <#=class1.Name#>()
{
	Initialize();

<# if (class1.HasPrimaryKey) {#>
	OnCreated();
<# } #>
}

private void Initialize()
{
<# 		  foreach(Association association in class1.Associations) { #>
	<#=association.Storage#> = <#
	if (association.IsMany) {
		#>new EntitySet<<#=association.Type.Name#>>(attach_<#=association.Member#>, detach_<#=association.Member#>);
<#			} else {
		#>default(EntityRef<<#=association.Type.Name#>>);
<#			}
}
#>
}
#endregion

And I moved the call to OnCreated() to the constructor. Now, the code behaves exactly the same, and I’m able to call Detach() without any side effects! Nice….

Btw, here’s a free T4 editor if you need one.

I’ve seen other solutions that involved copying the entity properties using reflection or using serialization.
They’re simply a lot slower. In my test, they both took around 60 ms. This Detach() method takes 0 ms! :p

Download my custom T4 template, which is based on this Codeplex project. You have to rename the file to Model.tt.