-
-
Notifications
You must be signed in to change notification settings - Fork 37
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
Target .NET Standard 2.0 instead of .NET Core 3.0 #21
Comments
From my understanding the only restricting requirement for the library having to target .NET Core is the Excel exporting functionality. If that is the case maybe it is better have it as a separate library than within the same if it means other platforms will not be able to use this. |
When we tried running |
as per Microsoft's 2.2 to 3.0 migration guidelines
<Project Sdk="Microsoft.NET.Sdk.Razor">
<PropertyGroup>
<TargetFramework>netcoreapp3.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<FrameworkReference Include="Microsoft.AspNetCore.App" />
</ItemGroup>
...
</Project> So I think for application till asp.net core 2.2 they can use 2.2.2 version of this package and from asp.net core 3.0 on wards they can refer newer version of this library. |
I have also dropped the |
Ah I see. I didn't know abot that issue. I wonder how other libraries are handling this sort of things. I'll also take a look when possible.
|
@JudeVajira thanks for the suggestion. It's time to make Excel export as a complimentary separate library like JqueryDataTablesServerSide.Reports. I'll start works related to this. |
Is your feature request related to a problem? Please describe.
I think its better to target .NET Standard 2.0 or 2.1 instead of a specific framework as using a specific framework would reduce the availability of the Library. As any project that does not target .NET Core 3.0 or above would not be able to use it.
As shown in the above image. If .NET Standard 2.0 or 2.1 is targeted it would reach a wider audience. Generally speaking it is always better for a library to be written using .NET Standard instead of targeting a specific framework when possible.
Describe the solution you'd like
I hope we could revert back to .NET Standard 2.0 instead of targeting .NET Core 3.0
The text was updated successfully, but these errors were encountered: