Add support for .net project & file references #789
Conversation
|
|
||
| resolve(path, [target]) { | ||
| // Both / and \ are supported as the path separator so we need to normalize it to / | ||
| target = target.replace(/\\/g, '/'); |
There was a problem hiding this comment.
Just asking myself whether this functionality should be part of relativeFile so other plugins can benefit from it as well.
There was a problem hiding this comment.
I was thinking that too. There's also a number of spots doing what relativeFile does manually, not sure if any of them would benefit from this though.
There was a problem hiding this comment.
Ohh I wasn't aware of this. Maybe worth tackling this in a separate Pull Request at some point.
There was a problem hiding this comment.
Should I add this into relativeFile or do that in a separate PR with #796?
There was a problem hiding this comment.
I would tend to do this in a separate PR, but feel free to make it part of this PR.
| <!-- @OctoLinkerResolve(Directory.Build.props) --> | ||
| <Compile Include="../Directory.Build.props" /> |
There was a problem hiding this comment.
@stefanbuck what value should these resolve to? The test results seem to be pointing to nuget.org instead of github.com.
There was a problem hiding this comment.
If these links are meant to be relative the annotation needs to be
// @OctoLinkerResolve(<root>/dotnet/Directory.Build.props)
<root> will be replace with https://github.com/OctoLinker/OctoLinker/tree/e2e/fixtures when generate the test data out of all fixtures.
However, this does not explain why the test is pointing to nuget.org.
There was a problem hiding this comment.
Strange, I checkout out this PR and hooked up everything locally. Navigating to
does not link this line at all.There was a problem hiding this comment.
Well the casing of /Classic/ is different on disk. However, the next include does not work either
There was a problem hiding this comment.
The path casing was wrong. Classic should have been all lowercase. Switching that fixes it.
There was a problem hiding this comment.
The tests are passing now for these, but some other ones are failing that aren't related to this change 😕
There was a problem hiding this comment.
For some odd reason, E2E tests are timing out way more often on PRs than on master. Let's get this merged and we will see what happens 😉
xt0rted
force-pushed
the
dotnet-project-references
branch
from
4179e3d
to
94beb90
Compare
Checklist:
Adds support for project and file references inside of csproj and friends. It supports both the classic and newer sdk style formats.
Linkifying files might not be the best on large projects since you could potentially have tens of thousands of files, but that's only an issue when using the classic style. In my own testing of a project with 1,006 added links I didn't notice any additional slow down but I'm also using a core i7 6900k with 64gb of ram so this might not be the best test machine.
Project references
File references
Closes #450