Skip to content
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

V4 Development: TargetFrameworks #3314

Open
2 tasks
danielmarbach opened this issue May 8, 2024 · 2 comments
Open
2 tasks

V4 Development: TargetFrameworks #3314

danielmarbach opened this issue May 8, 2024 · 2 comments
Labels
feature-request A feature should be added or improved. module/sdk-core p2 This is a standard priority issue v4

Comments

@danielmarbach
Copy link
Contributor

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

  • I may be able to implement this feature request
  • This feature might incur a breaking change

AWS .NET SDK and/or Package version used

None

Targeted .NET Platform

None

Operating System and version

None

@danielmarbach danielmarbach added feature-request A feature should be added or improved. needs-triage This issue or PR still needs to be triaged. labels May 8, 2024
@ashishdhingra
Copy link
Contributor

Needs review with the team. CC @normj

@ashishdhingra ashishdhingra added needs-review v4 and removed needs-triage This issue or PR still needs to be triaged. needs-review labels May 8, 2024
@normj
Copy link
Member

normj commented May 10, 2024

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.

@ashishdhingra ashishdhingra added the p2 This is a standard priority issue label Jun 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request A feature should be added or improved. module/sdk-core p2 This is a standard priority issue v4
Projects
None yet
Development

No branches or pull requests

3 participants