I'm migrating our DAL class library to .NET 4 (from .NET 3.5). We're using typed datasets quite often, and we often iterate over tables:
foreach(var row in ds.MyTable) var tmp = row.ID;
This does not work anymore, as the designer changes the dataset's code so that tables do not derive from TypedTableBase<T>
anymore, but from DataTable
(and implement the non-generic IEnumerable
). That's what the diff shows. Therefore, the row is of type object
at compile-time.
Does anybody know if this is the usual behavior? At the moment, I'm doing it the way shown below, but I hope there's a more elegant solution:
foreach(var row in ds.MyTable.Cast<MyDs.MyRow>()) var tmp = row.ID;
The accepted answer is mostly complete, but will not fully resolve the issue.
Here's a reproduction of my question and answer on this issue.
The Problem:
In short, the problem occurs when the
MSDataSetGenerator
tool runs, but theSystem.Data.DataSetExtensions
assembly has not yet been loaded into the current Visual Studio process.The Solution:
One way to load the assembly is just to open any XSD file and THEN re-generate the designer code.
The following steps should generate the appropriate designer file:
Run Custom Tool
Here's a full step by step walkthrough of the issue and solution with pictures
Other Instances:
This problem has also been reported to Microsoft in the following bug tickets:
All this is correct but in my case I had to support source code which needs to run with .Net 2.0 and .Net 4.0. My objective was to change as little code as possible.
My solution was to create a partial extension under .Net 4.0 and bind it to the 4.0 application. This looks like:
This works like a charme!!!
Just ran into this today and was able to correct it by doing the following:
Select the xsd files in the solution explorer and click "Run Custom Tool". The designer files will be regenerated using TypedTableBase instead of DataTable and IEnumerable.