search

influxdata / influxdb-csharp

A .NET library for efficiently sending points to InfluxDB 1.x
Apache License 2.0
199 stars 60 forks source link

Future of .NET Framework support #56

Closed cypressious closed 6 years ago

cypressious commented 6 years ago

I noticed that in the dev branch, the full .NET Framework is no longer targeted. Is there any particular reason?

nblumhardt commented 6 years ago

Hi! .NET Standard 2.0 supports .NET Framework 4.6.1 onwards - are you stuck with an earlier version?

(Just keen to simplify here, nothing deeply against supporting earlier versions.)

cypressious commented 6 years ago

My main application is a ASP.NET MVC 4 application running on .NET 4.6.1. Because of MVC, I have to use the old style .csproj format.

When I add a .NET Standard package, the following stuff gets added to my packages.config:

  <package id="System.Collections" version="4.3.0" targetFramework="net461" />
  <package id="System.Console" version="4.3.0" targetFramework="net461" />
  <package id="System.Globalization" version="4.3.0" targetFramework="net461" />
  <package id="System.Linq" version="4.3.0" targetFramework="net461" />
  <package id="System.Net.Http" version="4.3.3" targetFramework="net461" />
  <package id="System.Net.Sockets" version="4.3.0" targetFramework="net461" />
  <package id="System.Runtime" version="4.3.0" targetFramework="net461" />
  <package id="System.Runtime.Extensions" version="4.3.0" targetFramework="net461" />
  <package id="System.Security.Cryptography.Algorithms" version="4.3.0" targetFramework="net461" />
  <package id="System.Security.Cryptography.Encoding" version="4.3.0" targetFramework="net461" />
  <package id="System.Security.Cryptography.Primitives" version="4.3.0" targetFramework="net461" />
  <package id="System.Security.Cryptography.X509Certificates" version="4.3.0" targetFramework="net461" />
  <package id="System.Threading" version="4.3.0" targetFramework="net461" />

Subsequently, the packages are also added to the .csproj file.

Independent of whether it works at runtime or not, I would like to prevent cluttering my project files.

That's why I would like to encourage you to keep separate .NET Standard and .NET Framework support in the library.

gambrose commented 6 years ago

@cypressious It is possible to convert your .net project to use the new PackageReference style nuget. I have done this a work, where we are running .net 4.6.2 and MVC. It makes for much nicer nugget experience. I used NuGet PackageReference Updater. VS 15.7 adds support for migrating but this migration tool is still in beta

cypressious commented 6 years ago

@gambrose I tried to convert a project of mine but it didn't work with the NuGet PackageReference Updater. Maybe because it's a ASP.NET project, not sure.

Anyway, I think it's worth it to keep supporting .NET 4.5 to make integration easier.

nblumhardt commented 6 years ago

Thanks for the additional info/investigation, all! I think that while the additional package references are a bit of a wart at present, they're a point-in-time problem that the tooling is likely to address very soon. Keeping maintenance load low on this project is a pretty high priority right now, and so I think sticking with the .NET Standard simplification is the way to go.

cypressious commented 6 years ago

For reference, I managed to get the dev version targeting .NET Standard 2.0 running in a .NET framework 4.6.1 application by letting Visual Studio generate bidning redirects (see https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/how-to-enable-and-disable-automatic-binding-redirection#enabling-automatic-binding-redirects-in-web-apps). That's not ideal, especially for people like me who primarily use Rider.

@nblumhardt I respect your decision to prioritize simplification. But maybe you can rethink your decision, especially since the new .csproj format makes multitargeting very easy.