Inedo.UPack Issues

Issues Overview

44	2.1.0	enhancement	closed	Add more overloads to PackageBuilder that accept CompressionLevel

45	2.1.0		closed	Drop explicit targeting of net5.0

43	2.0.4	bug	closed	FIX: InvalidDataException returned instead of 401 on ListVersionsInternalAsync

42	2.0.3	enhancement	closed	Add dependencies to RemoteUniversalPackageVersion
please add dependencies to RemoteUniversalPackage. else we have to Download a package first to see the dependencies.
21	2.0.0		closed	Use System.Text.Json instead of Newtonsoft.Json on all platforms that support it

33	1.1.1		closed	FIX: UniversalPackageVersionRange.Parse should allow unbounded ranges

32	1.1.0		closed	Add version range support to package dependencies

27	1.0.10		closed	InstallationDate of installed packages is mangled when installing other packages
Newtonsoft.Json has the annoying design decision to parse dates as dates when possible. Due to the way the registered packages are deserialized and reserialized when calling `PackageRegistry.RegisterPackageAsync` all dates of previously registered packages are parsed and reformatted using the default date formatter. https://github.com/JamesNK/Newtonsoft.Json/issues/862 I expect other fields to get the exact same treatment and this would be extremely bad if it happened to a `group` or `name` field that is parsable as a `DateTime`. This can be fixed by either fixing #21 not only for NET Core 3.1, but for all targets supporting System.Text.Json. Another option could be to not rely on dynamic deserialization in Newtonsoft.Json. Steps to reproduce 1. Register a package using .NET reversible format `o` 2. Register a second package using .NET reversible format `o` Expected result Both packages are listed in `installedPackages.json` with the date provided to the `RegisterPackageAsync` method. Actual result The `installedDate` of the first package is mangled and changed into the default date format (MM-dd-YYYY) instead of the actual string.
28	1.0.10		closed	UniversalPackage leaves file stream open when a corrupt file is passed in
When using the constructor `UniversalPackage(string fileName)` on a corrupt zip file or a file that is not a zip file the constructor will crash and leave the file handle open. Steps to reproduce 1. Create a corrupt `.upack` file 2. Execute the following code ``` try { using (var upack = new UniversalPackage(packagePath)) { return upack.GetFullMetadata(); } } catch (InvalidDataException) { while (true) File.Delete(packagePath); } ``` Expected result I would expect the failing constructor to clean up the file handle making it possible to delete the file on failure. Actual result File handle is not released for corrupt packages. (it may be released after a long time by the garbage collector, I'm not sure)
22	1.0.8		closed	FIX: Local package repository fails to look up by package name with an empty group

23	1.0.8		closed	Normalize invalid semver versions that have leading zeroes when looking up local package by version

24	1.0.8		closed	FIX: Search packages does not work for local repositories

25	1.0.8		closed	FIX: Add strong name key [regression]