-
Notifications
You must be signed in to change notification settings - Fork 124
Sort by Project References to avoid project ordering dependency issues. #1109
base: master
Are you sure you want to change the base?
Sort by Project References to avoid project ordering dependency issues. #1109
Conversation
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Still relevant. |
@arikalish this seems like good code to resolve NU1605 errors. Do you know why it is not building? |
@promontis Unfortunately not. A lot of PR builds from the time I submitted this PR (and some others) failed for mysterious reasons. Unfortunately, I think it would require a maintainer to resolve the issues as they seem to be with the build pipeline. The tests that fail are kind of strange, honestly. |
@krissetto @CrispyDrone @skolima @rajbos any help is appreciated 🙏 |
I've generated some automated updates... and yes, the pipeline is failing. I'll see if I can work out why. |
microsoft/azure-pipelines-agent#3501
|
@arikalish this looks IMO like it was a test failure and was solved by #1113 - could you please update from main branch again? |
@skolima sure. I'll update all my PRs today! |
Cool! All is green 👍 Can this be merged @skolima? |
I like this. However, there was kind of a "feature". Nukeeper usually failed when some references were unnecessary, due to this matter. Do you think its useful to have an option to opt-in, to check for unnecessary package refs? |
I'd like to dig into this a bit more before going "OK". @msallin I'm not fond of "accidental features" like this - there's dedicated tools to trim the dependencies tree. |
Yes. I agree. It should be accidental. |
I use ReSharper for this, but seems that VS also has this built-in now https://stackoverflow.com/a/67715612/3205 . I've also used |
@skolima FWIW: We've added some tests to our solution that pinpoint unused project references using Roslyn but they haven't solved this issue. Also, for folks (perhaps unwisely) using reflection it can be difficult to detect unused references correctly. IIRC |
Yes the way dotnet-outdated does it really nice: https://github.com/dotnet-outdated/dotnet-outdated/blob/846207a9f656f8504f13a4fc51abacb85796c072/src/DotNetOutdated.Core/Services/DependencyGraphService.cs#L28 It shells out to msbuild to create the This could also be done in memory using msbuild directly, and picking the appropriate SDK owned msbuild using MSBuildLocator (I've been doing this with a bit of success in other metaprogramming projects). There is a fair bit of logic that could be simplified in NuKeeper by using MSBuild directly, like evaluating project graphs and and getting PackageReferences "from the horses mouth", with metadata taking us to the source lines they were defined. |
@slang25 the catch with this approach - and the reason we avoided it before - is that it doesn't work with .NET Framework Classic. And at least when we looked at this (khem, khem, 2017 I think) it would have been much more complicated, if not completely unsupported. It might be time to revisit that approach, but keeping in mind that a significant feature of NuKeeper over other tools is that it works with the Classic Framework. |
@skolima |
@skolima how is the code looking so far? Would be awesome if this can be merged 🎉 |
@skolima have you had time to look into the code? Hopefully, this can be merged soon. |
✨ What kind of change does this PR introduce? (Bug fix, feature, docs update...)
Bug fix
Packages to update are sorted by the packages they reference but ignores project dependency ordering, leading to issues when projects at the root of the dependency graph are updated before those that depend on them that are more than one level in the tree apart from one another. In particular, this leads to ERROR NU1605: https://docs.microsoft.com/en-us/nuget/reference/errors-and-warnings/nu1605
🆕 What is the new behavior (if this is a feature change)?
Sorts by project reference before sorting by package dependencies.
💥 Does this PR introduce a breaking change?
Possibly, but this was tested on a fairly large solution (175+ projects) with a very complex dependency graph and it did not cause any issues.
🐛 Recommendations for testing
Project dependency graph like this:
A -> B -> C -> D
Where -> means "references".
A and D reference the same package. Update the version referenced by D. I had some trouble replicating this in a simple solution, but was able to replicate it consistently with our large solution.
📝 Links to relevant issues/docs
Similar to: #988
🤔 Checklist before submitting