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.
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.