mamift · Oct 20, 2026 · Sep 15, 2026 · Sep 15, 2026 · Sep 15, 2026 · Sep 15, 2026
diff --git a/.claude/settings.local.json b/.claude/settings.local.json
@@ -12,7 +12,10 @@
       "Bash(dotnet run *)",
       "Bash(DOTNET_MULTILEVEL_LOOKUP=0 dotnet exec \"LinqToXsd/bin/Debug/net7.0/LinqToXsd.dll\" gen \"LinqToXsd.Schemas/XInclude/xinclude.xsd\" -c \"LinqToXsd.Schemas/XInclude/xinclude.xsd.config\" -o \"LinqToXsd.Schemas/XInclude/xinclude.xsd-g.cs\")",
       "Bash(echo \"EXIT: $?\")",
-      "Bash(git stash *)"
+      "Bash(git stash *)",
+      "mcp__fuse__fuse_workspace",
+      "mcp__code-review-graph__get_minimal_context_tool",
+      "Bash(dotnet test *)"
     ]
   },
   "enableAllProjectMcpServers": true,

diff --git a/.gitignore b/.gitignore
@@ -263,3 +263,6 @@ Samples/
 *.diff
 LinqToXsd.Schemas/_temp/
 .fuse/
+*.DS_Store
+.github-issues/
+.scratch/
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -0,0 +1,41 @@
+# Contributing to LinqToXsdCore
+
+IMPORTANT BEFORE DOING ANY WORK: Please use the [LinqToXsd-TestingSuite.slnf](https://github.com/mamift/LinqToXsdCore/blob/testing/dublincore-xhtml/LinqToXsd-TestingSuite.slnf) solution filter file when working with this repo in Visual Studio or Rider. The full `sln` file has projects that currently do not build.
+
+Mandatory requirements before your PR is accepted or approved:
+
+1. **When contributing, please summarise your pull request in such a manner that it is acceptable to be included in the `RELEASENOTES.md` file** that is packaged in every nuget release (look at the release notes for previous releases to get an idea - be short but descriptive enough to point someone in the right direction if they want to dig deeper - this includes referring to Github issues and PRs). 
+    - You do not have to update the `RELEASENOTES.md` file yourself but write a summary that's sufficient to be included there. This means that you should NOT GET OVERLY TECHNICAL IN YOUR PR DESCRIPTION. Please use [Github issues](https://github.com/mamift/LinqToXsdCore/issues) for that and refer to the issue in your PR description.
+
+2. **ENSURE THAT YOU WRITE A TEST FOR YOUR CHANGES.** Tests are incredibly helpful when collaborating with other developers - they help ensure that new contributions do not break existing functionality. Fixing a bug? Write a test to ensure the bug does not re-occur. Adding a feature? Add a test to cover the feature behavior or output.
+
+3. **ENSURE THAT YOUR CHANGES DO NOT BREAK EXISTING FUNCTIONALITY.** All tests should pass (including test written by you). 
+    - There are some existing tests that are broken when run as part of the full suite, *but work when run individually* (`TestGenerateCodeFromSingleDirectoryWithAutoConfig` for instance) - these are acceptable failures. 
+    - For tests that are broken and need updating, please annotate them such that they still run *but are not counted as failures or ignored* (see `TestGetFullPathFromSchemaInGraph`),
+    - Or that they need to be explicitly run by the user (see `PrototypeSplitByNamespaceAndClass`), so wil not run during the CI/DevOps builds.
+4. In the solution root there's a PowerShell script: `Regenerate-TestingSuite.ps1`. After all the tests in the testing project have been run (and pass), run this script to regenerate all C# code in the `GeneratedSchemaLibraries` folder. This is very helpful to catch regressions that are not covered in the test project. **Please try to fix any regressions found by this script alongside your PR! I WILL NOT APPROVE A PR THAT INTRODUCES A REGRESSION OR TEST FAILURE!** It is also helpful to have the changes in code generation captured in git from version to version to find and diagnose bugs, and to know which version may have changed ouptuts or behavior.
+    - Also: the script may generate new code files (i.e. not yet tracked in git) - if these new files cause build errors, THEN discard these files and their dependents.
+    - Ideally: *only commit code re-generated by the script for existing files that are tracked in git.*
+    - Finally: any code files that are changed by `Regenerate-TestingSuite.ps1` should be committed IN ITS OWN INDIVIDUAL COMMIT to make it easier to catch regressions. Ideally this commit should be the LAST commit in your PR branch and obviously, must build OK.
+
+For points 2. and 3. the preferred type of test is an end to end code generation test; so this counts as an integration test. Unit tests should be preferred when testing extension methods or you are making changes to the runtime library in `XObjectsCore`.
+
+## Use of AI
+
+We welcome the use of AI in your pull requests, so long as you follow the above rules - remember NO TEST FAILURES. And if your PR brings in changes that results in test failures, then those failures need to be fixed before the PR can be approved. AI coding agents should help you with fixing these.
+
+Much of the code base and indeed most of the test suite pre-dates AI coding agents (the original Microsoft code was written in 2008-2011 and was ported to .NET Core/.NET Standard in 2019), so as long as the existing test suite passes, then new code, even if AI generated is acceptable.
+
+## Optional things
+
+- Please consider contributing the full XSD file that exhibits any code generation bugs. In terms of cyclomatic complexity, the code base rates incredibly high, and as a result, LinqToXsd emits a very specific output, and is highly vulnerable to regressions in response to seemingly trivial code changes. 
+
+    It also does not cover the entire W3C XML Schema v1.0 specification - so when a code gen bug is discovered, it is incredibly helpful to have the full XSD file as many parts of the XML Schema specification interact in quirky ways when transposing it to C#. Some things simply cannot be handled by LinqToXsd as there currently exists no idomatic way to model an XSD concept or construct in C#. Having the XSD on file helps when new C# language versions are released, and they can be evaluated for future implementation.
+    - In cases where bugs from specific XSD files are unfeasible to fix in a single PR, please: 
+        - contribute the XSD file under it's own separate folder under the [GeneratedSchemaLibraries](https://github.com/mamift/LinqToXsdCore/tree/master/GeneratedSchemaLibraries) folder, 
+        - then run the `create individual xsd libraries.ps1` PowerShell script to automatically create a `.CSPROJ` file and link it to the greater solution. 
+        - This allows storing the XSD for future bug fixing and also segregating buggy code out in it's own project so that the other test projects can still build and run. Uncompilable code **should not be linked to the `XObjectsTests.csproj`** or the **`LinqToXsd.Schemas` projects**.
+
+- If the full XSD file cannot be given, then a minimal extract of the schema that exhibits the code generation bug is also acceptable. Many **code generation** tests simply make no sense unless there's an accompanying XSD file.
+
+Finally, the `AllEntCf.xsd-xml` schema is cursed; trying to run code gen on it will result in an out of memory error, even on systems with 32GB of RAM. I appreciate any efforts to get to the bottom of why this happens. But in the meantime, please refrain from using this file in any tests. You have been warned.
diff --git a/Directory.Build.props b/Directory.Build.props
@@ -4,6 +4,16 @@
   <!-- Build and design defaults -->
   <PropertyGroup>
     <RootNamespace>Xml.Schema.Linq</RootNamespace>
+    <!--
+      `dotnet build/test -f <tfm>` passes TargetFramework as a global property. By default
+      NuGet restore treats that as a request to restore only that TFM for every project in
+      the graph, so multi-targeted projects (XObjectsCore, XObjectsCodeGen) end up with an
+      assets file containing just that TFM. They are still referenced via SetTargetFramework
+      for their other TFMs (e.g. netstandard2.0) from projects such as LinqToXsd and
+      LinqToXsd.Schemas, which then fails with NETSDK1005.
+      Disabling NuGet's TFM override makes restore always cover all TargetFrameworks.
+    -->
+    <_DisableNuGetRestoreTargetFrameworksOverride>true</_DisableNuGetRestoreTargetFrameworksOverride>
     <!-- This is an opt-in feature of .NET SDK 10 that allows the LinqToXsd CLI tool to be packaged AOT; turned off for now as it triples the nupkg size -->
     <!-- <RuntimeIdentifiers>win-x64;win-x86</RuntimeIdentifiers> -->
   </PropertyGroup>
@@ -32,8 +42,9 @@
     CS1574: XML comment has cref attribute 'xsdFilePath' that could not be resolved
     CS1591: Missing XML comment for publicly visible type or member ...
     CS1734: XML comment on ... has a paramref tag for ..., but there is no parameter by that name
+    CS0108: warning CS0108: '...' hides inherited member '...'. Use the new keyword if hiding was intended
     -->
-    <NoWarn>$(NoWarn)1570;1574;1591;1734;NETSDK1138</NoWarn>
+    <NoWarn>$(NoWarn)1570;1574;1591;1734;0108;NETSDK1138</NoWarn>
   </PropertyGroup>
 
   <!-- Pack exisiting README file -->