Generated GraphQL classes not compatible with < .NET 6

[samnorr]

I just tried to use the generated GraphQL classes in a .NET Framework project, but for some reason wasn't able to access them... I then realized that they are specifically targeting .NET 6 and greater. Just wondering what the reason is for this - is it a restriction with the tool used for generating these? I would have thought it would be possible to keep compatibility for those of us still on .NET Framework?

I know there are already some plans to refactor these classes, so maybe this is already on the roadmap.

Thanks!

[nozzlegear]

Hey! I'm glad you asked, I forgot that detail myself and need to update the documentation. I believe it originally required .NET 6 or greater because it makes use of nullable primitives, which weren't supported in .NET Standard 2.0 or .NET Framework at the time. They are supported now though, so I believe (and apparently that AI believes) that requirement can be removed. I'll take a look and get a new version published!

[nozzlegear]

Hmm, looks like it's the use of the required keyword that prevents using it in anything under .NET 6. I should be able to do a string replace on it when generating them, just not sure if it would break anything.

@clement911 Any thoughts on making the required keyword configurable in Wish.GraphQLSchemaGenerator? I'd like to open up the generated classes for .NET Framework users, and I think this is the only thing that blocks that.

[clement911]

@nozzlegear I haven't had a chance to review the many changes that you have done recently.
Once I do, I will be in a better position to comment on the code generation of GraphQL entities.
That being said, I don't believe the generated classes have a required keyword, do they?

[nozzlegear]

No worries @clement911! Good question about the required keyword – I thought those were the error messages I was seeing, but it's possible that I broke another part of the project when I was trying to make the generated classes work in .NET Framework. I'll take a closer look tomorrow and see what's actually going on.

[clement911]

I remembered that the generator currently excludes .NET framework because the DateOnly type is not supported in .NET Framework.

I guess it could potentially generate a DateTime instead. 🤔

Do we really have to keep on supporting .NET Framework though?

[nozzlegear]

@clement911 Ah that makes sense, thanks for looking into it! As much as I'd love to drop .NET Framework support, there are too many ShopifySharp users who are still using it; I want to maintain as much compatibility with them as I can (within reason) for as long as Microsoft decides to keep it supported.

I think I see where the DateOnly type is configured in ShopifySharp.Tests/Services/Graph/GenerateGraphQLSchemaTest.cs – is that correct? A good solution here might be to keep the nice modern stuff for .NET 6+ that we have now, and then generate a second version that uses DateTime for .NET Framework.

[clement911]

I had a try but unfortunately DateOnly is the easy part.
The generated classes also heavily use default interface implementation, which is not supported on .Net Framework.

That being said, the generated classes are not needed to use the GraphService.
One can define their own classes to be deserialized to.

[samnorr]

@nozzlegear @clement911 Thank you both for looking into this.

Regarding the need for keeping .NET Framework support, I am definitely an example of a user that is quite tied to it.. I dread the day that we are forced to migrate our application to a non-Framework version, as not only would it be a major change in itself, but there are also some functions that outright wouldn't work on non-Framework, which we would need to try to find workarounds for. 😓

Although I totally understand that it can be a pain to have to keep the legacy compatibility with the library, and lose out on all the newer language features as a result. I guess at some point it may make more sense to split off ShopifySharp into a separate fork for .NET Framework (which would then of course require the extra effort to maintain the fork).

I am aware that defining your own classes to use with the GraphService is an option, and that is plan B in my case - however it does seem a shame to go that route and have to maintain all of the required classes separately, when they are already being included with ShopifySharp.

Fingers crossed that it's possible to adapt the schema generator for backwards-compatibility without too much hassle...

[chandrianos]

@nozzlegear @clement911 Are the generated classes going to be compatible with .NET Framework after all? We need to decide whether to wait for a new release or implement our own classes.

Thank you for your time.

[nozzlegear]

@samnorr Thanks for the explaining! It's my understanding that a lot of devs on .NET Framework are in a similar situation, just based on the correspondences I've had over the years working on ShopifySharp.

@chandrianos I'm going to take another whack at generating classes for .NET Framework.

I might need to use a different schema generation tool, as the one we use right now is one that @clement911 built for a separate work project and refactoring it for .NET Framework may not be his goal or within scope (I'll let him chime in there). I do have some other changes I'm wanting to make to the pre-generated classes for .NET 8, including #1133 and #1135, so that's a consideration as well.