aws / aws-sdk-net

The official AWS SDK for .NET. For more information on the AWS SDK for .NET, see our web site:
http://aws.amazon.com/sdkfornet/
Apache License 2.0
2.07k stars 862 forks source link

V4 Development: TargetFrameworks #3314

Open danielmarbach opened 6 months ago

danielmarbach commented 6 months ago

Describe the feature

Currently the v4 development branch uses rather interesting TFMs. As an example the unit tests use

<TargetFrameworks>netstandard2.0;netcoreapp3.1;net8.0</TargetFrameworks>

Netstandard2.0 is not a TFM you'd want to target for a unit test project.

Also what is netcoreap3.1 doing there?

Use Case

Development

Proposed Solution

From a TFM test matrix perspective if you care about a reasonable enough overlap I would suggest to target supported TFMs such as NET48 and current LTS and current non-LTS versions as long as they are supported

Other Information

No response

Acknowledgements

AWS .NET SDK and/or Package version used

None

Targeted .NET Platform

None

Operating System and version

None

ashishdhingra commented 6 months ago

Needs review with the team. CC @normj

normj commented 6 months ago

Yes I agree it is weird the test projects, which are executables, target .NET Standard 2.0. It was the quick and easy way to make sure we had some way to force the tests to run on the .NET Standard 2.0 target of the SDK. When the unit test projects .NET Core 3.1 then we get the netcoreapp3.1 version. I know you can force a version using the target in the ProjectReference using AdditionalProperties="TargetFramework=netstandard2.0" but that doesn't work well for our unit tests multi targetframework situation because we don't want to always use netstandard2.0.

I think the right solution would be to separate the testing for .NET Standard 2.0 into a separate unit project file that only has one target framework but then uses the AdditionalProperties="TargetFramework=netstandard2.0" in the ProjectReference. Just haven't gotten around to setting that up and updating the CI system.

As far as why the SDK still has the netcoreap3.1 is even though the framework is out of support we still have a lot of users that are still on .NET Core 3.1. The major decider when we drop a target is when the usage has gone down to some minimal level.