Dependency node fails to initialise when project does not define TargetFramework #6974
Assignees
Labels
Feature-Dependency-Node
"Dependencies" node in Solution Explorer that display project, binary & package references
Resolution-Fixed
The bug has been fixed, refer to the milestone to see in which release it was fixed.
Milestone
Comments
drewnoakes
added
Bug
Feature-Dependency-Node
|
cc: @edwardskrod |
drewnoakes
added a commit
to drewnoakes/project-system
that referenced
this issue
Feb 19, 2021
Fixes dotnet#6974 Currently, the logic is to construct these subscriptions _only_ when the `TargetFramework` or `TargetFrameworks` properties change. For a regular .NET project this is fine as that property will be defined, and when it is first observed it will trigger the subscriptions that allow the Dependencies node to function correctly. For a project type that does not define these properties (i.e. WAP projects) this logic is incorrect. This fix ensures a `AggregateCrossTargetProjectContext` when the current instance is null.
drewnoakes
added a commit
to drewnoakes/project-system
that referenced
this issue
Feb 19, 2021
Fixes dotnet#6974 Currently, the logic is to construct these subscriptions _only_ when the `TargetFramework` or `TargetFrameworks` properties change. For a regular .NET project this is fine as that property will be defined, and when it is first observed it will trigger the subscriptions that allow the Dependencies node to function correctly. For a project type that does not define these properties (i.e. WAP projects) this logic is incorrect. This fix ensures a `AggregateCrossTargetProjectContext` when the current instance is null.
ghost
added
the
Resolution-Fixed
This issue was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As part of making the Dependencies node work for WAP projects, I uncovered an issue where the node's data subscriptions are not constructed correctly.
Currently, the logic is to construct these subscriptions only when the
TargetFrameworkorTargetFrameworksproperties change.For a regular .NET project this is fine as that property will be defined, and when it is first observed it will trigger the subscriptions that allow the Dependencies node to function correctly.
For a project type that does not define these properties (i.e. WAP projects) this logic is incorrect.
The real fix is to tackle #6183. In the meantime we need a simple fix to unblock WAP projects.
The text was updated successfully, but these errors were encountered: