Closed MattKotsenas closed 9 months ago
I admit that the LicenseExpression change is a bit unjustified at the moment. I plan to stack another PR on top of this one that will use LicenseExpression and (hopefully) justify the change. If you object to that PR (or this portion of this PR) let me know and I can back the change out.
Does this need to update the public APIs? The build passed so I guess not?
Does this need to update the public APIs? The build passed so I guess not?
No because NuspecReader is in the unit test project and not the main lib. My upcoming PR moves this type to be internal to the main lib, hence the refactoring.
Does this need to update the public APIs? The build passed so I guess not?
No because NuspecReader is in the unit test project and not the main lib. My upcoming PR moves this type to be internal to the main lib, hence the refactoring.
Ah sorry, been a long day where I've been looking at a lot of different things. I'll merge.
Add two new properties to NuspecReader:
LicenseUrl
LicenseExpression
LicenseUrl
Maps to the
<licenseUrl>
element, which can be set by thePackage
, but could never be read. Also update unit tests to validate values.Note that as part of this PR I changed the domains for the sample URLs to use the TLD
.invalid
. While it really doesn't matter, using the .invalid TLD (reserved in RFC2606) is ever-so-slightly more correct, and avoids the possibility of accidentally trying to resolve these fake domains in the future.LicenseExpression
A helper that returns the value of
<license>
if the license type is "expression". This centralizes what is otherwise a slightly gnarly ternary expression to disambiguate license expressions from license files:The
Package
class currently can't create packages with a<license type="file">
. This addition is a preparatory refactoring for an upcoming change to move the NuspecReader as an internal member of the main library.Also added a unit test.