Errors that don't exists

Jun 18, 2009 at 1:07 AM

Hi all,

I am putting this into use and have quite an extensive XSD that I apply it to.  Every thing works fine accept in visual studio it says that I have a number of errors, but the project builds and runs from the debugger just fine.  These errors all have to do with the created objects from the XSD.  'ADATDataSet' is the parent element.

Error 1 The type or namespace name 'ADATDataSet' could not be found (are you missing a using directive or an assembly reference?)

Any ideas as to why this is happenning?





Jun 19, 2009 at 3:42 AM

Just an FYI...

For anyone that might want to know.  This was a project that did not previously have any LinqToXml cababilities until I just recently tried to add it by editing the project file.  Setting the XSD "Build Action" to LinqToXSDSchema.  I began seeing the error's on the extension methods that I had created for the root object.  The extension methods previously used a CS file generated from the XSD.exe command line tool.

Today I set the XSD build action to none, used the LinqToXSD.exe command line tool to generate a CS file and compiled it into the project.  Now there are no errors showing up.

The thing that is wierd though is that even though I was seeing the errors in VS2008 yesterday it still compiled and ran successfully.



Jun 20, 2009 at 10:36 AM
Edited Jun 20, 2009 at 11:59 AM

I experienced the exact same behaviour in Visual Studio 2008. In my case it was caused by ReSharper 4.5. If you disable the ReSharper Plug-In all imaginary errors will disapear and IntelliSense will work rstraight away. I figured this out by trying LINQ to XSD in Visual Studio 2010 where it worked as a charm.


Jul 8, 2009 at 5:53 AM

Some schemas present a corner case (see, for example, part of the namespace and the name of one of the elements are the same. In above example the schema has a definition for graphml element.

For such cases (see TypeBuilder.cs) XWrapperTypedElementBuilder.AddTypeToTypeManager() method should add a "global::" prefix to clrTypeInof.clrFullTypeName - the same way it does it for innerTypeFullName.

My patch for line#924 in TypeBuilder.cs:

wrapperDictionaryStatements.Add(CodeDomHelper.CreateMethodCallFromField(Constants.WrapperDictionaryField, "Add", CodeDomHelper.Typeof("global::" + clrTypeInfo.clrFullTypeName), CodeDomHelper.Typeof(innerTypeFullName)));

This patch fixed the problem.


Thanks for your excellent stuff, guys.

Good luck,