"failed to validate against any of the oneOf schema" isn't a sufficiently detailed error

[FlaggAC]

If I get a validation error inline in the VSCode editor, I'll get specific info on what the error is, such as "String does not match the pattern of "(^[A-Z][a-z0-9]+[A-Z]$)|(^[A-Z][a-z]+$)|(^[A-Z][a-z0-9]+([A-Z][a-z0-9]+)+$)|(^[A-Z][a-z0-9]+([A-Z][a-z0-9]+)+[A-Z]$)".

But with this library, I'm getting "failed to validate against any of the oneOf schema".

Is there any workaround for this? I did some debugging into the internals but came up short.

I'm unable to use v4 with roslyn analyzers on .net 8 consumers due to dependency conflicts with the .net standard 2.0 version of the library (especially System.Collections.Immutable), so I'm using the latest 3.x. Not sure if that would make a difference.

Thanks for all the work anyway, nice to see more options for this.

[mwadams]

You need to set the ValidationLevel to Verbose and it will then tell you why each of the subschema failed (or passed).

Can you show me an example of the issue you are having with your Analyzer scenario? We've got a fair bit of experience dealing with that particular challenge and can usually figure it out...eventually.

[FlaggAC]

Unfortunately when I use verbose mode I get 219 errors instead of just the 1 I am expecting. My project is a game server that aims to allow customizations through json, assisted by validators, so it's not an option.

This seems to be how vscode does it - The basic principle is when a oneOf is encountered, automatically choose the subschema that is the "best match", then use that subschema automatically for reporting errors if any. It seems like a good approach. I could try to implement this if needed and use some kind of patch.

Example code from my repo:

• Schema that is linked to the validation error with this package
• The subschema that should be linked with the error like in vscode
• The line triggering the error due to the underscore in property name

P.S. Is version 3.x still supported at all? I don't think it will be possible to use v4.x until fully upgrading to .NET 9, which may be impossible for me to do until some of the other transitive dependencies are ported to .NET 9. Roslyn contexts can be pretty unforgiving with transitive dependencies as I've found out recently :(

No problem either way, it's not really urgent to address as I was able to get enough of a PoC working to be on board with my overall approach with the schema validation pipeline.

[FlaggAC]

For the Analyzer dependency issue, I don't have the exact steps to reproduce, it was a lot of trial and error. But the general idea is that Roslyn analyzers can only use .NET Standard 2.0, but they are consumed from projects targeting .NET 8. And the net80 project needs to have manual references to any transitive dependencies that are actually used. And the dependencies must be compatible with all other dependencies in both projects. The Microsoft error messages related to this are often not great either and are subtle and easy to miss, they only show up as warnings.

There were some packages I noticed that had an exact version requirement, and the System.Collections.Immutable being >= 9.0.0 was something I couldn't work around, as the net80 project was hard locked at 8.0.0 (I don't think the package I need for testing the roslyn generator even has an update that supports 9.0.0 yet).

You can see many commented lines from things I was doing to try to fix earlier today:
https://github.com/ACRealms/ACRealms.WorldServer/blob/41e4d2fa010806ceab810f32b25c0bf686f09926/Source/ACRealms.RealmProps/ACRealms.RealmProps.csproj

Here's the actual error diagnostic class, which is separate from the code generator (code generators generally can't emit errors due to performance reasons)
https://github.com/ACRealms/ACRealms.WorldServer/blob/41e4d2fa010806ceab810f32b25c0bf686f09926/Source/ACRealms.RoslynAnalyzer/ACRealms.RoslynAnalyzer/Generators/ACR20XX_RealmProps.cs

[mwadams]

For the Analyzer dependency issue, I don't have the exact steps to reproduce, it was a lot of trial and error. But the general idea is that Roslyn analyzers can only use .NET Standard 2.0, but they are consumed from projects targeting .NET 8. And the net80 project needs to have manual references to any transitive dependencies that are actually used. And the dependencies must be compatible with all other dependencies in both projects. The Microsoft error messages related to this are often not great either and are subtle and easy to miss, they only show up as warnings.

There were some packages I noticed that had an exact version requirement, and the System.Collections.Immutable being >= 9.0.0 was something I couldn't work around, as the net80 project was hard locked at 8.0.0 (I don't think the package I need for testing the roslyn generator even has an update that supports 9.0.0 yet).

Right - this is all a horrible nightmare. We have been through this process with creating a SourceGenerator for V4. We ended up doing what System.Text.Json does for its analyzers and symlinking all the code we actually need, and entirely removing other dependencies.

It's worth pointing out that the 9.0 versions of those packages do work on the .NET 8 runtime, though; the STS packages are all backcompat with the preceding LTS runtime, and there are also netstandard2.0 binaries in the 9.0 packages. You

It is notable that in VS, the analyzers now all run in an external .NET 8 process, so I'm hoping we don't have to contend with quite so much nonsense in a future releases.

However, using our generated code in analyzers and also "generating code as part of other source generators" are goals we've got in several scenarios, and this would be a good one to work through.

P.S. Is version 3.x still supported at all?

We are still supporting 3.x for critical bugfixes, security etc.

[mwadams]

Unfortunately when I use verbose mode I get 219 errors instead of just the 1 I am expecting. My project is a game server that aims to allow customizations through json, assisted by validators, so it's not an option.

This seems to be how vscode does it - The basic principle is when a oneOf is encountered, automatically choose the subschema that is the "best match", then use that subschema automatically for reporting errors if any. It seems like a good approach. I could try to implement this if needed and use some kind of patch.

Ha! It looks for the match with the least number of actual errors and says "yeah - that one was pretty close" :)

I'll try and figure something out for you that will be a) reasonably efficient and b) back-portable to the 3.x series.

[mwadams]

I could merge the errors for all the failed schema if oneOf passed 0. You can then pick out what you want for yourself.

[FlaggAC]

Isn't that the same as running it in Verbose?

[mwadams]

No - verbose includes all the keywords of all the schema, both passed and failed; it is a full annotation of the entire evaluation.

'Detailed' gives you failures and additional contextual information.

I can also expose the code that gives you the line and column offset of the errors in the target document(s) if you have the source docs.

[FlaggAC]

I can also expose the code that gives you the line and column offset of the errors in the target document(s) if you have the source docs.

I think that would be a huge help, that way in visual studio the error can be double clicked on to jump to that line.
As long as the errors have contextual data for which subschema it is AND a way to identify the parent oneOf schema then I can just have the analyzer report the errors for the subschema having the fewest errors, and discard the errors for the other subschema(s). I just need to make sure that the errors aren't being reported for the oneOf subschema that isn't the intended schema for the user code