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

Add additional TFM to eliminate explicit dependency #380

Closed
thompson-tomo opened this issue Apr 13, 2024 · 7 comments · Fixed by #381
Closed

Add additional TFM to eliminate explicit dependency #380

thompson-tomo opened this issue Apr 13, 2024 · 7 comments · Fixed by #381
Assignees

Comments

@thompson-tomo
Copy link
Contributor

Is your feature request related to a problem? Please describe.
I want to minimise dependencies in my project by utilising framework dependencies wherever possible

Describe the solution you'd like
I want the package to have an additional TFM (net 6) added so that the explicit dependency on System.Text.Json can be removed.

Describe alternatives you've considered
Accept the additional dependency

Additional context
n/a

@axunonb
Copy link
Member

axunonb commented Apr 14, 2024

Agree, NET60 is LTS and should become a target framework. Any reason not mentioning NET80 which is also LTS? Or newer NET80 instead of NET60?

@axunonb axunonb self-assigned this Apr 14, 2024
@thompson-tomo
Copy link
Contributor Author

My preference is to target older frameworks ie net 6 so that more projects can benefit & only add the latest TFM where there is a benefit ie new language features or additional libraries bundled into the framework.

@axunonb
Copy link
Member

axunonb commented Apr 29, 2024

Targeting net60 looks more complex than expected:

  • Migrating SmartFormat.ZString to net60 brings 56 warnings about nullability and type conflicts we cannot simply ignore. They all come from the fork of Cysharp.ZString v2.5.1
  • BuildingCysharp.ZString v2.6.0 with netstandard2.0, netstandard2.1 and net60 works fine (of course), but the build targeting .NET 4.6.1 is breaking. They implemented nice improvements, but the methods don't exist for .NET 4.6.1, This was somehow to be expected, because they dropped .Net Framework support since quite a while.
  • We could reference Cysharp.ZString v2.6.0 directly as a nuget package, and offer the NetStandard2.0 build as the replacement for the native.NET 4.6.1 build. This results in a breaking change for .Net Framework users.
  • We could freeze the .NET 4.6.1 build down to Cysharp.ZString v2.5.1 that we currently use. For the other target frameworks we reference Cysharp.ZString v2.6.0 nuget package. Feasible, but increases complexity.

@karljj1 @thompson-tomo Appreciate your thoughts about the best way to go.

@thompson-tomo
Copy link
Contributor Author

My thoughts would be to switch to 2.6.0 nuget rather than the fork to improve maintaince going forward. If I am not mistaken you should be able to consume a net standard 2.0 library in net framework 4.6.1 hence I think we might be ok. If it doesn't then we should evaluate bumping the major so net framework can be dropped &/or conditional compilation. Could we conditional just the nuget hence maintenance should be more manageable.

@axunonb
Copy link
Member

axunonb commented May 8, 2024

Yes, taking netstandard2.0 assemblies for .NET 4.6.1 would be nice, and all tests succeed. So we could keep .NET 4.6.1 as a target fx and still reference Cysharp.ZString v2.6.0.
Not sure, whether this should be considered a breaking change? I tend to "no". What do you think?

@thompson-tomo
Copy link
Contributor Author

I also wouldn't consider it a breaking

thompson-tomo added a commit to thompson-tomo/SmartFormat that referenced this issue May 12, 2024
axunonb pushed a commit that referenced this issue May 12, 2024
* #380 Add net 6 to STJ project and make other dependencies conditional
* Optimize package properties.
* Fix nullability and warning issues for Demo and Performance projects
axunonb added a commit that referenced this issue May 15, 2024
* Reference to Cysharp ZString v2.6.0 package (#382)
* Reference Cysharp `ZString` v2.6.0 in `SmartFormat` project (net461 target use the netstandard2.0 assemblies)
* Remove project `SmartFormat.Zstring`
* Move internal static class ZStringBuilderExtensions to namespace SmartFormat.ZString
* Rename ZStringBuilderExtensions to ZStringBuilderUtilities
* Exclude ZString wrappers from code coverage (#384)
* Flag `ZStringBuilder` and `ZStringWriter`with `[ExcludeFromCodeCoverage]`
* Add AltCoverAttributeFilter="ExcludeFromCodeCoverage" in CI tests
* #380 Add net60 as additional target framework (#381)
* #380 Add net 6 to STJ project and make other dependencies conditional
* Optimize package properties.
* Fix nullability and warning issues for Demo and Performance projects
* chore: net60/ZString related housekeeping (#385)
* Directory.Build.props: Remove duplicate entries from Demo and Performance projects
* Enable NRT for Demo and Performance projects
* Remove folder SmartFormat.ZString from former projects SmartFormat.ZString
* Remove obsolete entries from SmartFormat.sln
* Remove reference to former SmartFormat.ZString.dll from SmartFormat.csproj
* Enable net60 for project SmartFormat (#387)
* feat: Add net8.0 as a target framework (#388)
* Mark CTOR overload (System.Runtime.Serialization.SerializationInfo info, System.Runtime.Serialization.StreamingContext context) as obsolete (like it is in net8.0).
* Update proprocessor directives and nuget packages
* Change appveyor_build_worker_image to Ubuntu2204
* Add net8.0 as target framework
* Update target framework net461 to net462
* Bump version to v3.4.0

---------

Co-authored-by: James Thompson <thompson.tomo@outlook.com>
@axunonb
Copy link
Member

axunonb commented May 15, 2024

Resolved with #389

@axunonb axunonb closed this as completed May 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants