feat: Add Support for .Net Standard 2.0

[rogerbarreto]

• Resolves Add support for .netstandard 2.0. #89
• Fixes a Vulnerability Flag for Text.Json 8.0.0
• Add missing .gitignore and .editorconfig suppressions.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[yyyu-google]

Hi @rogerbarreto thank you so much for your contribution on this. There are two testing projects https://github.com/googleapis/dotnet-genai/blob/main/Google.GenAI.Tests/Google.GenAI.Tests.csproj and https://github.com/googleapis/dotnet-genai/blob/main/Google.GenAI.E2E.Tests/Google.GenAI.E2E.Tests.csproj

Currently they target net6 and net8, so the net6 will test the netstandard2.1 assembly and net8 will test the net8 assembly. If you would like to include netstandard2 into Google.GenAI, we need to make sure that the two testing projects test against the netstandard2 assembly as well.

Once the testing projects test against netstand2 assembly, we also need to update

dotnet-genai/.github/workflows/dotnet-tests.yml

Line 26 in bac5fd5

dotnet-version: |

to make sure the CI will test the 3 assemblies.

Do you have some ideas how to make sure the test coverage over the 3 assemblies?

Again thank you very much for this PR.

[rogerbarreto]

@yyyu-google Thanks for the ask, currently when I was attempting in doing so I noticed that the dependency TestServerSdk package didn't support netstandard2.0 and pushed a PR there.

• .NET: Add netstandard2.0 support google/test-server#59

Once we have a valid version for the TestServerSDK I'm happy pushing another PR or this one whatever suits best to cover the netstandard2.0 scenarios.

[stephentoub]

Is the netstandard2.1 target necessary? Even for the core .NET library nuget packages we don't include a target for that. It was kind of a misfire. I'd suggest just replacing the netstandard2.1 TFM with netstandard2.0.

[yyyu-google]

I will do a release to the TestServerSdk soon, to enable netstandard2. will reply here once ready

[yyyu-google]

Hi, I got into some urgent tasks, so there will be a little delay on updating the TestServerSdk for netstandard2.

Meanwhile, if this PR is urgent, here is the TestServerSdk https://github.com/google/test-server/tree/main/sdks/dotnet repo, we welcome PR :)

Otherwise, please allow me some more time for the TestServerSdk update.

[yyyu-google]

Is the netstandard2.1 target necessary? Even for the core .NET library nuget packages we don't include a target for that. It was kind of a misfire. I'd suggest just replacing the netstandard2.1 TFM with netstandard2.0.

yes netstandard2.1 is necessary, and it is requested by another user. moreover, we'd like to support modern unity developers.

[yyyu-google]

Thank you for the patience. I have updated the TestServerSdk to 0.1.6 if you update the dependency version, you should be able to write tests against the netstandard2.0 target now.

[yyyu-google]

Thank you @rogerbarreto for the PR, it looks good to me. I just followed @stephentoub 's advise to use net8 to test all the targets of this repo, like in #145

Could you do a similar change to the e2e tests and unit tests to test the netstandard2.0?

A special reminder to update https://github.com/googleapis/dotnet-genai/blob/main/.github/workflows/dotnet-tests.yml to reflect the test on the new targets for GitHub workflow. Thank you!

[rogerbarreto]

@yyyu-google Changes made to the PR, took liberty also to:

1. Add the missing solution file to help having whole visibility of the projects and help building all of it.
2. Added some missing .editorconfig configurations to avoid warnings during compilation that were not being considered for the current build pipeline.
3. Fixed some XmlDoc inconsistencies
4. Removed web-sockets package as a dependency as it was not being used at all and was forcing the override of the Transitive System.Net.Security to avoid a vulnerability, discussed as part of this PR fix: Address vulnerable dependencies #135