Open danielmarbach opened 6 months ago
Needs review with the team. CC @normj
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.
Describe the feature
Currently the v4 development branch uses rather interesting TFMs. As an example the unit tests use
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