Posts in category .net - page 19

Discarding new entity objects in LINQ to SQL beta 1

An unusual bug in .NET Framework 3.5 beta 1 that relates to creating a new entity object in LINQ to SQL has been getting in my way.

Bug description

When you create a new entity object it is not automatically added to the database unless you either attach it to the table or create an association to another existing entity.

The problem arises when you decide to discard the new object instead of persisting it. Setting the property of the association(s) to null should achieve this and the LINQ to SQL designer code shows that it removes the new object from the association.

When SubmitChanges is called it is apparent that the new object has not been discarded but is in fact attempting to persist to the database.

Reproduction

  1. Create a new C# Console project
  2. Add a new a LINQ to SQL file and name it Northwind
  3. Use Server Explorer to drag Orders and Customers tables from a Northwind database connection
  4. Paste the following code snippet into the static main method
  5. Run the program
  6. Examine the Orders table and notice a new a record consisting of null fields
NorthwindDataContext dc = new NorthwindDataContext();
Customer alfredCustomer = dc.Customers.Single(c => c.CustomerID == "ALFKI");
Order newOrder = new Order();
newOrder.Customer = alfredCustomer;
newOrder.Customer = null;
dc.SubmitChanges();

Workaround

It would appear there is at least a temporary workaround which is to force the association that was modified to reload. You can do this by calling the associations Load method after the entity has been de-associated but before SubmitChanges.

In our reproduction this would therefore be:

newOrder.Customer = null;
alfredCustomer.Orders.Load();
dc.SubmitChanges();

Calling Load does not disrupt other still-valid associations that have not yet persisted.

Curiously accessing the Count property of the association also causes the problem to disappear because the EntitySet<T> class that is responsible for representing these one-to-many associations calls Load every time you access Count. This is a potential performance hit as accessing a Count` property is considered to be a fast operation that does not go off and rebuild collections.

Here’s hoping that Microsoft fix those two bugs before release and ideally before beta 2.

[)amien

DiffMerge is free, try it with AnkhSVN

SourceGear, known for their Vault source control software, are giving away their three-way diff & merge tool DiffMerge for Windows, Mac and Unix.

DiffMerge has a clear interface and supports for file-type specific rule-sets that allow you to decide how to deal with white-space, line-endings, encoding etc.

I’ll be using it instead of my trusty KDiff for a couple of weeks to see how things go.

To use DiffMerge in AnkhSVN head into the Tools > AnkhSVN > Edit the AnkhSVN Configuration menu option and then paste each of the following command-lines into the associated configuration option.

DiffExePath

C:\\Program Files\\SourceGear\\DiffMerge\\DiffMerge.exe "%base" "%mine" /t1="Base version" /t2="My version"

MergeExePath

C:\\Program Files\\SourceGear\\DiffMerge\\DiffMerge.exe "%base" "%theirs" "%mine" /r="%merged" /t1="Base version" /t2="Their version" /t3="My version"

Alternatively you might want to check out Trevor Green’s instructions on using DiffMerge with TortoiseSVN if you are not yet sold on AnkhSVN and it’s Visual Studio integration.

[)amien

AnkhSVN and Visual Studio 2007/2008/Orcas

A newer registry file is available to provide AnkhSVN with Visual Studio 2008 and Vista support in one.

If you are using Visual Studio 2007/2008/Orcas/9.0 you will have found that AnkhSVN 1.01 doesn’t appear in the IDE.

Like many Visual Studio add-ins AnkhSVN should work just fine but won’t appear because the installer does not write an entry for it in the 9.0 section of the registry.

In this case the specific branches are:

  • 32-bit HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\AddIns\Ankh
  • 64-bit HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\8.0\AddIns\Ankh

All we need to do is export that section out, change the 8.0 to 9.0 and then run it back into the registry.

This technique should work for any other add-in’s you have that are only appearing in 2005.

If you installed AnkhSVN into the default folder try these registry files I have prepared for 32-bit or 64-bit machines.

[)amien

LINQ to SQL NullReferenceException on SubmitChanges

I’ve been busy working on some LINQ to SQL (formerly DLINQ) apps that have been going well bar a NullReferenceException thrown at me from deep in the bowels of LINQ and it’s change tracker. A cursory glance in debug showed none of the properties that represent columns were null…

The null was actually a collection property that represented a one-to-many relationship that was automatically created using the foreign key constraints in the database. Normally this is set to an empty EntitySet however I was failing to call the default constructor from my new useful constructor.

The moral of the story is always call the default constructor with this(), especially when extending generated code. So much for persistence ignorance.

public partial class Invoice {
  public Invoice(int number) : this() {
    this.number = number;
  }
}

[)amien