-
Notifications
You must be signed in to change notification settings - Fork 52
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
Replace Specflow.Internal.Json with System.Text.Json #373
Conversation
This seems like a wholly good thing: I wouldn't expect users to be affected by expanding the set of supported JSON language features and removing custom libraries in favour of standard components helps our maintainability. It looks like the specs and system tests are currently failing, including some failing of the code-behind generation. |
As far as I remember, in the VS extension we parse back the json with a "standard" json parser, so probably there will be no issues there. But I will double check. |
I hope for the best that you get this to work. As we supported multiple different MSBuild versions back then, the used assembly versions were different for each. I don't know which VS Versions are supported by Reqnroll, but I would suggest doing a manual test with all of them to see if the MSBuild Task still works for everyone. Don't rely on the automatic tests for this one. |
I think additional testing is a good thing for this PR, but I can't do it. On my private machine I don't have the resources to test all supported Visual Studio versions. Do you have a tip where we could look first? (Compiling in Visual Studio, command line, etc). On the positive side, since v2.2.0 we already have a transitive dependency on It looks like MsBulid in .NET 6 can load System.Text.Json 6.0 without including the assembly. But this caused JIT errors because the SourceGenerator used System.Text.Json 8.0 specific APIs. That's why the SystemTests failed. So a workaround might be to use only 6.0 specific APIs and avoid the SourceGenerator. But that's not a clean solution, so I tried to provide the correct assemblies in the NuGet package. That way we deploy and run what we specify. |
I will do some testing with a VM configured for 17.8. In this list I have found that 17.6 will go out of support in a few days. No info on 17.7, but last time when we had VS problems, people reported issues with 17.8.3 that is one year old, so probably good enough for testing. |
Found this: https://endoflife.date/visual-studio |
Unfortunately as @SabotageAndi suspected, the things are not that easy. Trying to build on a machine with a clean VS 17.8.3 installation (that installs only .NET 8 by default) I get a compile error:
looking into it... |
with once I compile with |
It seems that the problem is that the I have an idea to fix it, so hold on. |
I have fixed the old VS compilation error with force loading the dependencies from the package |
🤔 What's changed?
Replaced all places where Specflow.Internal.Json is used with System.Text.Json.
Used SourceGenerator when possible to avoid reflection for serialization.
⚡️ What's your motivation?
SpecFlow and with it Specflow.Internal.Json is end-of-life.
With this PR all dependencies to specflow are gone.
Also System.Text.Json supports comments in reqnroll.json.
🏷️ What kind of change is this?
♻️ Anything particular you want feedback on?
Areas where JSON serializer was used:
AppInsightsEventSerializer
)BindingProviderService
)reqnroll.json
configuration file during runtime (JsonConfigurationLoader
)reqnroll.json
configuration file during generation (JsonConfigurationLoader
)Notes:
BindingProviderService
also used Specflow.Internal.Json. This has also been replaced by STJ. But there aren't many unit tests, and I haven't tested it with the Visual Studio plugin, so additional manual testing is required.📋 Checklist: