-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
error CS1061: 'object' does not contain a definition for 'TypeDefinition' #44
Comments
You have to use a configuration file with CLR namespaces mapped to XML namespaces. See this folder for an example (it already uses the same XSD you're using): https://github.com/mamift/LinqToXsdCore/tree/master/LinqToXsd.Schemas/XSD |
Thanks for getting back to me. I don't think this is the issue. I used the command line option to generate a sample configuration file and modified the CLR namespace mapping:
The configuration file you linked to only maps a single namespace, but the configuration generator generated two namespaces. I removed the second namespace from the config and I still get the same error message. The code generates two namespaces regardless of whether I map only one or both namespaces. There's a strange namespace www.w3.org.XML.Item1998.@namespace which is generated and I don't know where it picked it up from. Am I using the wrong XMLSchema.XSD?
|
OK took a second look and it appears to be a regression bug with the code generator; it's supposed to prepend the The link I gave earlier does contain compilable code generated from an earlier version of LinqToXsdCore that did not exhibit the bug so in the meantime it might be worth just copying the code from the above folder instead of generating it yourself. |
OK. No problem. I was one of the contributors to libXML way back in the 90s. For my project, I also investigated using XSLT and after 15 minutes I ran back screaming to .NET. I can't believe XSLT still doesn't have a built-in, comprehensive set of functions for text operations such as word wrap, space trimming, etc. The idea of using XML to write functions isn't appealing. While I Don't expect LinqToXsd to have a wide range of text operations, the .NET framework and or whatever templating language makes it a non-issue. |
May I ask what you're using LinqToXsd for? It's not meant as a replacement for XSLT, but I guess depending on how you use it, it can render XSLT redundant. The LINQ to XML API is probably better suited as a replacement for XSLT, especially if you don't actually have access to a schema for the XML you're trying to process. LINQ to XML is what LinqToXsd actually uses and depends on. With respect to text operations, LinqToXsd doesn't really provide any additional text/string manipulation facilities beyond what's already in the .NET API ( Conceptually this library is a couple levels above XSLT, even a level above XQuery even, because of the types it generates. |
You'll hate me for it, but I'm writing an XSD to Ada source code generator. I'm using C# and .NET as a springboard or booster to generate XSD data structures in Ada. They will be used in implementing the Ada code generator in Ada. At that point, I can jettison the .NET/C# booster since it's recreated it in Ada. It's kind of hard to wrap your head around as it is recursive at the architectural level. The reason for this weird strategy is two-fold. First, the tooling and libraries available for Ada development is sad. It does have an XML parser, but for a language that advertises type safety, accessing elements by their string names, defeats the point. It's also painful to work with unless you write accessors for all the elements you're interested in. Hopefully, this project will assist it making XML more pleasant for others by simply generating the strongly-typed code for any XSD. Second, along the development process, I can use the .NET booster code I've written as a reference for the Ada code. The languages are different, but the actual code generation is similar. I could just stop after completing the booster and release it as a .NET-based tool for Ada, but it's not a good advertisement for a language struggling in popularity, despite its impressive design and safety. |
That sounds like a very interesting project. Very niche though (not saying that's a bad thing!) And Ada is an intriguing language, but mapping XSD to Ada code should be easier than XSD to C#. It's interesting that parts of the XML Schema's type system already existed in Ada, like restricting a string type 'Weekday' to an enumeration of possible day names ('Mon', 'Tue', 'Wed'), or an int to a range of values. I wish you could do easily in C#! |
Yes, the restrictions should make it easier to implement it in Ada, but Ada is very pedantic which is a good thing considering you can get your code to run on the first execution. Ada is far more popular in Europe than in the US. |
Using the latest release 3.3.2, I generated XMLSchema.xsd.cs from XMLSchema.xsd and encountered the following errors:
The error seems similar to #10 (comment). You can repeat this by grabbing the XSD and running linqtoxsd on it:
wget https://www.w3.org/2001/XMLSchema.xsd
The text was updated successfully, but these errors were encountered: