What should be the minimum .NET Framework version about taglib-sharp

[Starwer]

To make it more clear, yes, it requires .NET 4.6.1.
This means that moving to .NET Standard 2.0 would phase out all compatibility with Windows Vista and older (https://docs.microsoft.com/en-us/dotnet/framework/get-started/system-requirements).

I didn't see a clear view on how it would make life easier on TagLib#. Getting code more compact is always a good thing, but I don't see it as a real driver.
My actual opinion: the minimum required .NET version should be .NET 4.5.
I think it is a bit too early to move to .NET 4.6.1. But I'd really like to see some concrete example of .NET 4.6.1 in action.

[decriptor]

I guess that is part of the question. Is there value in still supporting anything like Vista and older? It would be nice to take advantage of some of the newer C# features. I don't have any numbers as to what and where people are using TagLib#.

[Starwer]

Looking at this study: https://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10&qpcustomd=
It looks like Vista (0.84%) support is not a strong argument.
I doubt people using XP (still 9.17% !) are using it as a multimedia center/manager (which would indicate a need for TagLib#).
Supporting Windows 7 is a must have (47.2%), but no problem for .NET 4.6.1.

It would be nice to take advantage of some of the newer C# features

But what are these ? If someone says to me tomorrow: "Now we have moved to .NET 4.6.1. Please use the nice features of Net standard 2 from now on." I wouldn't know at all what to do about that. Can someone give a less vague advantage of .NET 4.6.1 and later ?

[Robin-Clemens]

Hello, a daily C# developer here. Also a user of this library.

There seems to be a slight misconception that targeting NET Standard 2.0 requires .NET 4.6.1
(Unless you plan on only targeting 1 framework, in that case NET Standard 2.0 actually requires you to target .NET 4.7.1 so you can load in the library into WPF, WinForm apps etc. )

Otherwise you will end up in .DLL hell
See: https://blogs.msdn.microsoft.com/dotnet/2017/10/17/announcing-the-net-framework-4-7-1/

Applications that target .NET Framework 4.6.1 through 4.7 must deploy additional .NET Standard 2.0 support files in order to consume .NET Standard 2.0 libraries.

And believe me, having working with that for the last 1.5 years. It will deploy a LOT of support .dlls

Now, its not all bad.
(See https://weblog.west-wind.com/posts/2017/Jun/22/MultiTargeting-and-Porting-a-NET-Library-to-NET-Core-20 for a reference example btw)

What it comes down to, and what you probably want. Is Multi-framework targeting,

Long story short, with the new .csproj format you can now do stuff like:

<Project Sdk="Microsoft.NET.Sdk">
	<PropertyGroup>
		<TargetFrameworks>netstandard2.0;net45;net40</TargetFrameworks>
	</PropertyGroup>
	<ItemGroup>
		<PackageReference Include="Newtonsoft.Json" Version="10.0.2" />
	</ItemGroup>
	<PropertyGroup Condition=" '$(TargetFramework)' == 'netstandard2.0'">
		<DefineConstants>NETCORE;NETSTANDARD;NETSTANDARD2_0</DefineConstants>
	</PropertyGroup>
	<ItemGroup Condition=" '$(TargetFramework)' == 'netstandard2.0'">
		<PackageReference Include="System.Data.SqlClient" Version="4.4.0-preview1-25305-02" />
	</ItemGroup>
	<ItemGroup Condition=" '$(TargetFramework)' == 'net45' ">		
		<Reference Include="mscorlib" />
		<Reference Include="System" />
		<Reference Include="System.Core" />
		<Reference Include="Microsoft.CSharp" />		
		<Reference Include="System.Data" />
		<Reference Include="System.Web" />
		<Reference Include="System.Drawing" />
		<Reference Include="System.Security" />
		<Reference Include="System.Xml" />
		<Reference Include="System.Configuration" />
	</ItemGroup>
	<PropertyGroup Condition=" '$(TargetFramework)' == 'net45'">
		<DefineConstants>NET45;NETFULL</DefineConstants>
	</PropertyGroup>
</Project>

This multi framework targeting allows you to target more then 1 framework for your class library (and as you can see in the example it targets both .NET 4.0, 4.5 and NET Standard 2.0)

Though note, you need Visual Studio 2017 for this. But it will play nicely along one another.

Intellisense will show if a piece of code is incompatible with one of the targeted frameworks so its actually quite easy to maintain aswell.

[claudiuslollarius]

An advantage of moving to .net standard (version 1.4 if possible since 2.0 cuts everything pre Fall Creators Update) would be having the library available on .net Core, UWP, as well as Xamarin in addition to traditional desktop .net

I am using a modified version of the native taglib for my media tag editor: having taglib-sharp available on UWP would allow me to switch over.

Microsoft has released nuget packages for serialization and xmldocument for .net standard 1.4, which makes porting to it much less painful than it used to be.

[decriptor]

I just wanted to bump this issues and post this (now building) .net standard 2.0 port (includes net40 support through multi-targeting) PR to get more eyes on this - #88

[Starwer]

[EDIT] I've removed the following comment as this has been solved in #107. My apologizes for the noise I created.

This question becomes blocking on Windows after the .Net standard 2.0 integration. The Nunit Visual studio flow is now broken. This badly impacts the acceptance level of Windows developers to contribute to the project.
Nunit is picky on the version of .NET and the tests project hasn't been ported ton .Net standard 2.0.
Problem is that the tests project is now on .NET 4.5 and the Class project is on .NET 4.0. Moving Nunit part back to 4.0 is not straightforward as this is not supported by latest Nunit versions. Not sure that the Nunit 3 Test Adapter can still be used in .NET 4.0 (this enables to run Nunit tests in Visual Studio).

As a result, I've now a strong preference for .NET 4.5 to make the Nunit compatibility easier. And I would greatly appreciate help to make Nunit work again on Visual Studio.

[decriptor]

I decided to go with net462 and netstandard 2.0