onizet / html2openxml

Html2OpenXml is a small .Net library that convert simple or advanced HTML to plain OpenXml components. This program has started in 2009, initially to convert user's comments from SharePoint to Word.
MIT License
306 stars 107 forks source link

Maintaining previous framework support #73

Closed twsouthwick closed 3 years ago

twsouthwick commented 4 years ago

I noticed a recent change that change support to .NET Framework 4.8 and .NET Standard 2.1. Is there a reason for this? That will prevent anyone from using the product on .NET Core 2.1, or any framework less than 4.8. Are you aware that a lower version will run on the higher? Unless you need features in .NET 4.8, you're fine to target 4.0/4.5/etc. The support for framework/core is dependent on the runtime, not the target you are choosing.

Some documentation about this is here: https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/application-compatibility (it's about breaking changes, but explains how you can target an earlier version and run on a later version).

Even though .NET Framework 4.0 as a runtime is no longer supported, many .NET Framework 4.0 apps are still running on .NET 4.8. That's why the OpenXml library supports .NET 3.5+ (since the .NET 3.5 runtime is still supported as well), and targets .NET 3.5, .NET 4.0, .NET 4.6, .NET Standard 1.3, and .NET Standard 2.0. I'll probably add .NET Standard 2.1 support soon so we can use some nullable reference types, but I'll keep the previous versions around (although .NET Standard 1.3 may be dropped in the next major release as I'm not aware of a runtime that is still supported that doesn't support .NET Standard 2.0).

onizet commented 4 years ago

Hi Taylor,

I have already started to work on the next major release, which will replace my regex-based HTML parser by AngleSharp. They only support .NET Framework 4.6+ and .NET Standard 1.3. So this means that in a meantime, this library will also drop support to .NET Framework 3.0 and 4.0.

My other concerns is about the dependency I have on System.Net.Http (.Net Framework 4.5+) and that I no longer want to support 2 different ways to download images. The reason is also about the configuration because I'm currently rely on System.Net.WebClient as a fallback and the latter requires to set Proxy and Credentials on the instance. I would like to rely on a factory (like IHttpClientFactory) and let the consumer handle proxy, credentials and logging on their side.

So I'm agree to step back and still support .Net Standard 1.3. But what do you advice about the HttpClient ?

twsouthwick commented 4 years ago

That's a tough one and a call that makes sense. I just wanted to make sure you didn't drop support for platforms that use your library 👍

I can totally understand just targeting.NET 4.6 and standard 1.3 (or even 2.0) so you can use some of those nice things (and not have as many compiler defines) . I would recommend getting a build out of the same version that can work with new OpenXml versions. The next minor version will expose a proper API to add items in order and then you'll be good to forget about this major version and move on 😁

You could also provide an interface that you would require platforms that don't use httpclient to implement for use so you don't have to maintain it. Not sure what your user base is, though, so just an idea.