Improve source generator usage

[Turnerj]

There are 3 main things this PR does:

• The source generator now uses the latest previews of System.Text.Json
  This helps work around other weird Visual Studio behaviour when compiling the code and versions etc
• Adds the flags so we can debug source generators via Visual Studio
  This is an amazingly useful feature!
• Reverts to using a file for schema generation
  Something wasn't sitting right with me that our builds were not deterministic - it was up to the state of the JSON file downloaded. I thought via a file might be faster too but so far haven't seen that be the case.

With that last point, I think we can still semi-automate the updating process for the JSON file I've embedded via scheduled GitHub Actions. This might also allow us to support #165 more easily.

In theory, none of these changes should affect the output of Schema.NET, just the build/debugging process.

[Turnerj]

So now I've gone from "it builds in CI but doesn't build locally" to "it builds locally but doesn't build in CI"... 🤦‍♂️

Well more specifically: it builds via Visual Studio/MSBuild (.NET Framework) now but doesn't via dotnet CLI (.NET Core).

[RehanSaeed]

Perhaps we can add a CLI command to the tool to download the JSON-LD for us?

[Turnerj]

It would have to be an additional tool as we can't call the source generator one from CLI but yeah, we could have a thin schema download client. I still wouldn't want to call it in our own build process but it does simplify our updating process.

I'll mock something up as another commit to this PR.

[Turnerj]

So I've...

• Moved the JSON-LD file to a new data folder in the root directory (seemed to make sense now we have two tools share it)
• Added a basic .NET 5 CLI application that will download the latest file from Schema.org and save it to this folder

Seems to work pretty good.

[Turnerj]

I'm thinking in the future, using something like this with a scheduled GitHub Action to do this updating for us. That though is a whole separate thing we can handle another day.

[RehanSaeed]

I'm thinking in the future, using something like this with a scheduled GitHub Action to do this updating for us. That though is a whole separate thing we can handle another day.

We have to be careful with code that updates itself. We need to ensure there are no breaking changes, these normally fail the build/tests though. A better approach might be to have a GitHub action that raises a PR for us a bit like dependabot/renovate.

[RehanSaeed]

Seems reasonable to me 👍🏼.

[Turnerj]

We have to be careful with code that updates itself. We need to ensure there are no breaking changes, these normally fail the build/tests though. A better approach might be to have a GitHub action that raises a PR for us a bit like dependabot/renovate.

That's a good idea. I won't look too much into it yet but I think if we had something open a PR every time there was a new schema.org version, that would be useful.

[RehanSaeed]

It'd also then play nicely with the auto-generated release notes. There will be a manual step of clicking the publish button every so often though.