|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.
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`
Both packages are listed in `installedPackages.json` with the date provided to the `RegisterPackageAsync` method.
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
using (var upack = new UniversalPackage(packagePath))
I would expect the failing constructor to clean up the file handle making it possible to delete the file on failure.
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]|