v0: Maintenance

[yzhoholiev]

• Update dependencies and fix vulnerabilities
• Deprecate unsupported frameworks

[CLAassistant]

All committers have signed the CLA.

[rasmus]

A lot of good changes here, quite a lot braking as they are removing old (deprecated) .NET versions. Any specific reason why v1 won't cut it for you?

v0 builds currently aren't running due to the incompatibility with running Linux Docker containers on Windows GHA runners. So, getting something up and running that could actually make v0 releasable again (build and test) would be priority number one.

[yzhoholiev]

I agree, that those changes are considered breaking changes, unfortunately, there is no version available between v0.x and v1.x.
For our project, we are waiting for v1.x to be released before planning the upgrade as it also contains breaking changes.
At the same time, the main reason for these changes is. actually, to deprecate the netstandard1.6 as it is not supported and remove usage of vulnerable versions of dependencies.

[janrybka]

I agree, that those changes are considered breaking changes, unfortunately, there is no version available between v0.x and v1.x. For our project, we are waiting for v1.x to be released before planning the upgrade as it also contains breaking changes. At the same time, the main reason for these changes is. actually, to deprecate the netstandard1.6 as it is not supported and remove usage of vulnerable versions of dependencies.

As I understand, as long you don't use netstandard1.6 it won't affect versions of libraries in result service. We're using version "0.83.4713" in .net 8 service and all artifact libraries are in correct, updated version, working fine on .net 8 runtime (EventFlow.dll used from package is from netcoreapp3.1 folder). Vulnerabilities tools used on service and final docker image don't show problems.

As for vulnerable dependencies, we managed to get green even in current EventFlow state. "System.Data.SqlClient" in newest version is not a problem, but it lags behind .net releases and is not the best option when working with Azure SQL and for now we only identified this as problem (#1022).

[yzhoholiev]

I agree, that those changes are considered breaking changes, unfortunately, there is no version available between v0.x and v1.x. For our project, we are waiting for v1.x to be released before planning the upgrade as it also contains breaking changes. At the same time, the main reason for these changes is. actually, to deprecate the netstandard1.6 as it is not supported and remove usage of vulnerable versions of dependencies.

As I understand, as long you don't use netstandard1.6 it won't affect versions of libraries in result service. We're using version "0.83.4713" in .net 8 service and all artifact libraries are in correct, updated version, working fine on .net 8 runtime (EventFlow.dll used from package is from netcoreapp3.1 folder). Vulnerabilities tools used on service and final docker image don't show problems.

As for vulnerable dependencies, we managed to get green even in current EventFlow state. "System.Data.SqlClient" in newest version is not a problem, but it lags behind .net releases and is not the best option when working with Azure SQL and for now we only identified this as problem (#1022).

The main problem was with the EventFlow.MongoDB as it only uses netstandard1.6 which has vulnerabilities in System.Net.Http (CVE-2018-8292) and System.Text.RegularExpressions (CVE-2019-0820)

[yzhoholiev]

I can roll back some changes to make the PR more lightweight, such as replacing the System.Data.SqlClient, but everything else is worth keeping.

[janrybka]

If it's only about MongoDB then with small step you could add .netstandard2.0 to the list (like in Autofac case) or drop support for 1.6 and replace with new one. Still it'll be a smaller backward incompatibility.