Improve support for recursive dir inclusion #341
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Consider the scenario where we include multiple files from a relative path that's outside the project directory:
<PackageFile Include="..\..\docs\**\*.*" PackagePath="docs\" />
In this case, the natural expectation is that starting from the wildcard, the paths are reconstructed under the specified target package path, just as if we had added %(RecursiveDir)%(Filename)%(Extension) at the end of the `docs\` expression.
We don't do that right now, just appending a relative path that is invalid since it goes outside the package root scope (we add the full `..\..\` as part of concatenating the `RelativeDir`, which includes that).
Granted, this can be worked-around by just constructing the right package path via MSBuild or setting a Link property, but it should Just Work OOB.
This commit adds that support, including the (tricky) scenario where RecursiveDir isn't populated at all, as in the case of a file under ..\..\docs\foo.txt above (since the ** won't have matched any subdirs, it will be empty). So we need to detect the scenario by reading the actual wildcard include, if any.
kzu
force-pushed
the
dev/RecursiveDirPath
branch
from
a6d5d88 to
3b956d4
Compare
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Consider the scenario where we include multiple files from a relative path that's outside the project directory:
In this case, the natural expectation is that starting from the wildcard, the paths are reconstructed under the specified target package path, just as if we had added %(RecursiveDir)%(Filename)%(Extension) at the end of the
docs\expression.We don't do that right now, just appending a relative path that is invalid since it goes outside the package root scope (we add the full
..\..\as part of concatenating theRelativeDir, which includes that).Granted, this can be worked-around by just constructing the right package path via MSBuild or setting a Link property, but it should Just Work OOB.
This commit adds that support, including the (tricky) scenario where RecursiveDir isn't populated at all, as in the case of a file under ....\docs\foo.txt above (since the ** won't have matched any subdirs, it will be empty). So we need to detect the scenario by reading the actual wildcard include, if any.