Internet Explorer is no longer supported. Many things will still work, but your experience will be degraded and some things won't function. Please use a modern browser such as Edge, Chrome, or Firefox.

Issues Overview

442.1.0enhancementclosedAdd more overloads to PackageBuilder that accept CompressionLevel
452.1.0closedDrop explicit targeting of net5.0
432.0.4bugclosedFIX: InvalidDataException returned instead of 401 on ListVersionsInternalAsync
422.0.3enhancementclosedAdd dependencies to RemoteUniversalPackageVersion
please add dependencies to RemoteUniversalPackage. else we have to Download a package first to see the dependencies.
212.0.0closedUse System.Text.Json instead of Newtonsoft.Json on all platforms that support it
331.1.1closedFIX: UniversalPackageVersionRange.Parse should allow unbounded ranges
321.1.0closedAdd version range support to package dependencies
271.0.10closedInstallationDate 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` **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.
281.0.10closedUniversalPackage 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)
221.0.8closedFIX: Local package repository fails to look up by package name with an empty group
231.0.8closedNormalize invalid semver versions that have leading zeroes when looking up local package by version
241.0.8closedFIX: Search packages does not work for local repositories
251.0.8closedFIX: Add strong name key [regression]