v4.4.58

Release notes

Changes

• Implemented dependency update functionality for .NET projects
• Implemented TFCPS_CodeUnitSpecific_DotNet_Functions.set_dependency_version, which was still a stub that raised "Operation is not implemented." and therefore let scupdatedependencies abort as soon as a .NET-dependency actually had to be updated. It now writes the new version into the Version-attribute of the matching PackageReference in the project-file (the same project-file get_dependencies reads from) via the new testable static helper set_dependency_version_in_csproj_content, which changes only the declaration of the updated dependency and preserves the notation of the former version (an exact pin like [2.9.1] keeps its brackets, an unbracketed version stays unbracketed).
• Fixed that the dependency-update of a .NET-codeunit aborted with "Version-list can not be empty" for a dependency whose registry actually offers usable versions (observed for CommandLineParser in GRYLibrary). Root-cause: get_available_versions kept every NuGet-version whose string started with a three-part-version (regex ^\d+\.\d+\.\d+ without end-anchor), which also kept pre-release-versions like 2.9.2-ci-210; the following sorted(..., key=lambda v: Version(v)) then raised packaging.version.InvalidVersion for such a string, and the broad except Exception: return [] turned that into an empty version-list, which GeneralUtilities.choose_version could not handle. The version-selection was extracted into the new static method select_updatable_versions_from_nuget_versions, which keeps only plain three-part-versions (anchored regex ^\d+\.\d+\.\d+$) - the only format the rest of the update-logic supports anyway. All of the above is covered by new testcases in test_TFCPS_DependencyUpdates.py.