Infer <Link> missing attributes for files outside of project root
See original GitHub issueVisual Studio Version: 16.4.1
Summary: Right now, if a project contains a file outside of the project file’s subtree, it is displayed as if it was in the project folder. If there are more than a few of these, one likely wants them to be in some kind of structure and right now that can only be achieved by manually adding many “Link” attributes.
Eg., in a project we have ~50 entries like this. In this case it happens the paths are <repo-root>\src\Common\Interop\...
and the project is in <repo-root>\src\Microsoft.Win32.SystemEvents
<Compile Include="$(CommonPath)\Interop\Windows\Interop.Errors.cs">
<Link>Common\Interop\Windows\Interop.Errors.cs</Link>
</Compile>
<Compile Include="$(CommonPath)\Interop\Windows\User32\Interop.Constants.cs">
<Link>Common\Interop\Windows\User32\Interop.Constants.cs</Link>
</Compile>
etc. It makes no difference whether Link is an attribute or an element - you can see how this is a burden to write, maintain, and it adds noise to the project and changes to it. But what is being done here is so mechanical. Can we improve the heuristic so that we can use Link less?
Perhaps if Link is not present, instead of “put everything at the root” we could use a heuristic like “remove any prefix common to the project path, then represent remainder”. In this case, there is a common prefix: <repo-root>\src
. Removing that and representing the rest would put the files in the solution explorer inside Common\Interop\Windows, which is what we want in this case.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:3
- Comments:5 (5 by maintainers)
Playing around with this, we do already support this via globs, just not individual items.
The following:
Results in a tree like:
Going deeper into the tree:
Results in:
You can actually make use of this to do this individual items by globbing (I don’t want to see what this does to evaluation time!).
This will result in
Interop\Native
becoming the LinkBase.I’ll leave this open, but this bug basically becomes “do something smarter with individual includes”.
Build does not need this metadata, it is just for VS.