search

sillsdev / l10nsharp

A .NET localization library for Windows Forms applications.
3 stars 10 forks source link

L10NSharp is a .Net framework only package but is depended on by .Net Standard packages #116

Open hahn-kev opened 5 months ago

hahn-kev commented 5 months ago

For example SIL.ChorusPlugin.LfMergeBridge depnds on L10NSharp despite it being a .Net Standard package. This causes warnings like this every time you run a package restore:

warning NU1701: Package 'L10NSharp 6.0.0' was restored using
'.NETFramework,Version=v4.6.1, .NETFramework,Version=v4.6.2, .NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1, .NETFramework,Version=v4.7.2, .NETFramework,Version=v4.8, .NETFramework,Version=v4.8.1'
instead of the project target framework 'net8.0'. This package may not be fully compatible with your project.

taking a look at the NuGet dependancies there's no reason we couldn't upgrade this to support .Net standard is that correct?

ermshiperete commented 5 months ago

It uses System.Windows.Forms which I think isn't available in .NET standard.

tombogle commented 5 months ago

It should be possible to refactor this (as we did years ago with the libpalaso DLLs) so that the WinForms stuff is in a separate DLL with appropriate interfaces and logic to hook up UI stuff on Windows. I don't think the core localization logic is dependent on WinForms.

hahn-kev commented 5 months ago

It uses System.Windows.Forms which I think isn't available in .NET standard.

Forms are available in dotnet 5+, so it could multitarget framework and a modern version of dotnet with Win Forms.

hatton commented 5 months ago

@tombogle do you know if anything is using the UI parts? One option would be to just drop those and ask any clients using them to roll them in locally.

tombogle commented 5 months ago

Yes, the UI stuff is definitely being used by a large number of applications. You might be able to make a (weak?) case for requiring each of the applications to have their own implementations of the dialog boxes, but the L10nExtender is a pretty fundamental piece of the localization puzzle for the WinForms clients, so I think it would be a step backward to require each of them to implement that and maintain separate versions.

megahirt commented 2 months ago

I'm thinking that what is needed is for us to understand why SIL.ChorusPlugin.LfMergeBridge needs L10NSharp in the first place and refactor that dependency out.