I feel your pain, I have inheritted a project with 200+ strongly typed datasets, some I can look at, some break as soon as I open them in the designer. Others, and this is the bit that confuses me, break other datasets and not the one opened. I have a sneaking suspiscion that it is due to an incorrect checkin in clearcase, the file dates do not match for the xsd and their codebehind files. I'm currently deleting all the xsd's and tables, then replacing them with real objects and unit tests. :)
.02c Dave. -----Original Message----- From: "Greg Keogh" <[email protected]> Sender: [email protected] Date: Wed, 20 Oct 2010 13:17:27 To: 'ozDotNet'<[email protected]> Reply-To: ozDotNet <[email protected]> Subject: RE: AsEnumerable unpredictable >Now to find the software equivalent. AN uninitialised variable? Well, there's no code involved, so I'm now carefully comparing the environments. I notice that SDK 6.1, 7.0A and 7.1 are on my dev machine. The other machine only has 7.0A. Suspicious I think, as each contains xsd.exe which is responsible for generating XSD tool code. So I run the following test to see if the output files differ: @echo off "C:\Program Files\Microsoft SDKs\Windows\v6.1\Bin\xsd.exe" ColsDS.xsd /d /o:v61 /eld "C:\Program Files\Microsoft SDKs\Windows\v7.0A\Bin\xsd.exe" ColsDS.xsd /d /o:v70A /eld "C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\xsd.exe" ColsDS.xsd /d /o:v71 /eld They differ only by a version comment line. So it's not a problem with a particular version of xsd.exe., It may be the way the VS2010 is calling xsd.exe, possibly internally omitting the vital /eld switch to generate generic classes. The relationship between different versions of Visual Studio and the SDKs is rather muddy. Searching continues... Greg
