System.Data breaking changes in latest .NET Framework update

31 July 2007

UPDATE: The Program Manager at Microsoft in charge of this area of the .NET Framework has confirmed that this was a bug, and that it will be fixed in the next update.

We've noticed some breaking changes in the System.Data assembly, version 2.0.50727.1378, changes that will affect the way the XtraGrid works when adding new records. This is the version that gets installed with Visual Studio 2008 beta 2.

Suppose we have the following code (where the event handlers also log their execution):

  CurrencyManager manager = GetCurrencyManager(CreateView());
manager.CurrentChanged += new EventHandler(manager_CurrentChanged);
manager.ListChanged += new System.ComponentModel.ListChangedEventHandler(manager_ListChanged);
manager.CurrentItemChanged += new EventHandler(manager_CurrentItemChanged);
manager.ItemChanged += new ItemChangedEventHandler(manager_ItemChanged);

WriteLog("===Add");
manager.AddNew();
WriteLog("===End");

manager.EndCurrentEdit();

With the old version of System.Data, we would get this output:

  0: ===Add
1: ItemChanged e.Index:-1
2: ListChanged ItemAdded - old:-1, new:100
3: CurrentChanged
4: CurrentItemChanged
5: ===End
6: CurrentItemChanged
7: ItemChanged e.Index:-1
8: ListChanged ItemAdded - old:-1, new:100

With this latest version of System.Data, we get this instead:

  0: ===Add
1: ItemChanged e.Index:-1
2: ListChanged ItemAdded - old:-1, new:100
3: CurrentChanged
4: CurrentItemChanged
5: ===End

As you can easliy see there are no longer any events fired with EndCurrentEdit(). This is hugely problematic since there is no chance to find out when the adding of the current row has been completed.

As it happens, we can handle the new behavior when all the data operations are made through the grid and data controller (we are in control, of course), but in many cases our customers will make direct calls through the DataView or through the CurrencyManager instance. In this latter scenario, the DataController and real DataView will lose synchronization and have different views of the universe, causing unknown and unforeseen problems.

(Note that although I'm only talking about XtraGrid here, it's likely that this issue will affect other controls and applications as well, as well as other grid controls.)

We are in touch with Microsoft's CLR team to try and resolve this issue.

14 comment(s)
Juan Ignacio Gelos

Hi Julian,

We are already affected by this breaking change... note VS 2008 b2 has a GoLive licence and we were planning on deploying some applications that we have ready for production... except users can't add new records to the grids.

Is there anything we can do to workaround this issue?

Note that deploying just (only) the .NET framework 3.5 b2 REDISTRIBUTABLE on top of 2.0 and 3.0 breaks EXISTING (deployed) applications that target the 2.0 framework and previous versions of DXperience, even with requiredRuntime="2.0..." on their config files. We've tested this on a machine with an application that references the DXperience vol 6.1 suite.

Uninstalling the .NET Framework 3.5 on that machine doesn't suffice to solve the problem: we needed to uninstall the whole .NET framework: v3.5b2, v3.0 and 2.0, and reinstall v2.0 for the application to work again (even rebooting after each uninstall).

2 August, 2007
Jiří Neužil

Are there any news in this issue?

3 August, 2007
Jiří Neužil

Juan Gelos: I had same troubes as you has have, but there is no need to unistall 3.5 3.0 reinstall 2.0 and so on.... a get "old" System.Data (from my second operating system) and replace new System.Data by old one (in GAC_32 and in GAC_MSIL) everything now works correct with VS 2008 Beta 2 installed......

3 August, 2007
Juan Ignacio Gelos

Jiří Neužil: correct, I was researching the issue yesterday and found out about the assembly... hadn't thought about replacing it in the GAC thoug. Thanks for the tip.

I wonder if there's any way to install both assemblies in the GAC and force the applications to use the old version, because I think the actual assembly version is 2.0.0.0, even though the "file version" changes from 2.0.50727.838 to 2.0.50727.1378...

I suspect the new version is needed for applications that target LINQ.

3 August, 2007
Andreas Johansson

I have not been able to test this myself and I have not been able to find any microsoft information about this breaking change.

Breaking changes to existing framework version are mostly security related and this seems a bit far from being that.

Since you have insight in this problem maybe you can report it to http://connect.microsoft.com under the VS and .NET section to get it fixed or at the minimum an explanation for this breaking change.

3 August, 2007
Jiří Neužil

Hi, the solution which I described above is working only for rutnime, in VS 2005 (2008) dataset designer you get errors and you lost your *.designer.cs files for your datasets.....

4 August, 2007
Julian Bucknall (DevExpress)

All

No more news at present. We're still trying the "talk to MS" route.

Cheers, Julian

6 August, 2007
Jiří Neužil

Hi, I have reported this issue to MS connect site and here is their answer and solution:

connect.microsoft.com/.../ViewFeedback.aspx

7 August, 2007
Julian Bucknall (DevExpress)

All

I received this reply from the PM in charge of the DataSet in the .NET Framework: "I am aware of the issue that you’ve posted about. This was a regression introduced during Beta 2 that occurred as part of a fix for WPF. It has been fixed and will work correctly in RTM. Please let me know if I can help with anything else."

So everything should be OK with releases after this beta 2.

Cheers, Julian

7 August, 2007
Juan Ignacio Gelos

Sigh. Any chance they could post a hotfix for this problem pre-RTM? The go-live license isn't much use to us if we can't deploy applications due to this bug...

Cheers

7 August, 2007
Jiří Neužil

Is there any link for that hotfix?

8 August, 2007
Rices Huang

Anybody can fix this error on Windows XP?

Microsoft's solution only work on Vista.

14 August, 2007
Erick Thompson

This was a bug that was introduced in Beta 2. It has been fixed for Visual Studio 2008 RTM.

Thanks,

Erick

16 October, 2007
Hans Andersen

Does the sentence, "As it happens, we can handle the new behavior when all the data operations are made through the grid and data controller (we are in control, of course)", imply that I should expect to be able to add new rows if I use the grid control itself to do it?

In other words, if the user types stuff into new-row area of the grid itself, should they be able to add this new row to the grid?

As you say, you are in control, so it should be possible to work around the MS bug and make it work properly.

The reason I am asking is that I cannot get the add-new-row feature to work as described in issue Q22298 (www.devexpress.com/.../Q22298.aspx).

17 October, 2007

Please login or register to post comments.