Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect warning icons when ReferenceOutputAssembly="false" #2928

Closed
jnm2 opened this issue Oct 28, 2017 · 14 comments · Fixed by #6536
Closed

Incorrect warning icons when ReferenceOutputAssembly="false" #2928

jnm2 opened this issue Oct 28, 2017 · 14 comments · Fixed by #6536
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. Triage-Approved Reviewed and prioritized
Milestone

Comments

@jnm2
Copy link

jnm2 commented Oct 28, 2017

Whenever I use ReferenceOutputAssembly="false", no matter what the target framework is (even between csproj and wixproj), I get a warning symbol even though there are no build warnings:

image

In this instance:

ClassLibrary1.csproj:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net462</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <ProjectReference Include="..\ClassLibrary2\ClassLibrary2.csproj" ReferenceOutputAssembly="false" />
  </ItemGroup>

</Project>

ClassLibrary2.csproj:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net462</TargetFramework>
  </PropertyGroup>

</Project>
@Pilchie Pilchie added Area-New-Project-System Feature-Dependency-Node "Dependencies" node in Solution Explorer that display project, binary & package references labels Oct 31, 2017
@Pilchie Pilchie added this to the 15.6 milestone Oct 31, 2017
@natidea
Copy link
Contributor

natidea commented Nov 29, 2017

DevNotes: with ReferenceOutputAssembly="false", NuGet does not generate a project reference in the assets file:

      "frameworks": {
        "netstandard2.0": {
          "projectReferences": {}
        }
      },

This likely means a ResolvedProjectReference item is not produced. However this does not seem to be a problem in Microsoft.NET.Build.Extensions.Tasks.csproj which resolves its project reference correctly. Investigating further...

@Pilchie Pilchie modified the milestones: 15.6, 15.7 Jan 24, 2018
@Pilchie Pilchie assigned etbyrd and unassigned natidea Mar 30, 2018
@Pilchie Pilchie modified the milestones: 15.7, 15.8 Mar 30, 2018
@Pilchie Pilchie modified the milestones: 15.8, 16.0 Jul 3, 2018
@evgeny-burmakov
Copy link

Do we have any workaround for hiding icon or reference?

@davkean davkean assigned drewnoakes and unassigned etbyrd Sep 27, 2018
@evgeny-burmakov
Copy link

Any news?

@evgeny-burmakov
Copy link

I have tried Dev 16 Preview and behavior is still observed. Any plans to fix it at upcoming version?

@drewnoakes
Copy link
Member

@evgeny-burmakov thanks for your patience. It's definitely on the radar. This issue will be updated as soon as there is any progress.

@drewnoakes drewnoakes added Triage-Approved Reviewed and prioritized and removed Triage-Approved Reviewed and prioritized labels Jan 15, 2019
@drewnoakes drewnoakes modified the milestones: 16.0, 16.1 Jan 29, 2019
@ReubenBond
Copy link
Member

ReubenBond commented Feb 13, 2019

I believe this is the reason why we see warning icons in VS in Orleans. We use a ProjectReference with SkipGetTargetFrameworkProperties set in order to ensure correct build order (codegen must be built before projects which rely on it).

image

If I add a condition '$(DesignTimeBuild) != '' to the ProjectReference then the warning icon (and dependency) disappears but build inside VS fails.

image

@davkean
Copy link
Member

davkean commented Feb 14, 2019

Haven't tried, but Visible on the reference should be respected. If not, that's probably a different bug.

@ReubenBond
Copy link
Member

Visible does hide the project, but the warning icon on the Dependencies node remains

@davkean
Copy link
Member

davkean commented Feb 14, 2019

@drewnoakes This will be a case of dependency node expecting a counterpart design-time builds result for the item it finds in evaluation.

@drewnoakes
Copy link
Member

Seems likely. I'll test my repro solution for this issue as part of the work I'm doing on #4550.

@drewnoakes drewnoakes modified the milestones: 16.2, 16.3 Jun 13, 2019
@drewnoakes drewnoakes modified the milestones: 16.3, 16.4 Sep 5, 2019
@drewnoakes drewnoakes modified the milestones: 16.4, 16.5 Nov 1, 2019
@drewnoakes drewnoakes modified the milestones: 16.5, 16.6 Dec 10, 2019
@jhudsoncedaron
Copy link

We track this issue. Same ultimate cause: project has a special build step which causes it to need a non-build dependency on another project. Useless visual studio warning icon with no actual warning.

@davidwengier
Copy link
Contributor

The established norm for referencing source generators as a project reference is to use OutputItemType="Analyzer" ReferenceOutputAssembly="false" so hits for this could start to increase with .NET 5. I mention this mainly so that searching for "Source Generator" correctly finds this issue, and because I happen to be using source generators a bunch at the moment 😁

@dmonroym
Copy link
Member

Related to dotnet/msbuild#1916

davkean added a commit to davkean/project-system that referenced this issue Aug 21, 2020
drewnoakes added a commit to drewnoakes/project-system that referenced this issue Aug 21, 2020
Project resolution has historically been determined by the presence of an item in the ReferencePath group, for which the source was a ProjectReference.

When a ProjectReference specifies ReferenceOutputAssembly=false, it is explicitly stating that the referenced project's output assembly should not be included in ReferencePath. However, for the purposes of populating the Dependencies tree, we still wish to know that this item was present. Its absense from the ResolvedProjectReference item group results in a yellow triangle appearing on the reference in the tree.

To fix this, we override the target used by the ResolvedProjectReference rule to also return ProjectReference items having ReferenceOutputAssembly=false.

Fixes dotnet#2928
drewnoakes added a commit to drewnoakes/project-system that referenced this issue Aug 21, 2020
Project resolution has historically been determined by the presence of an item in the ReferencePath group, for which the source was a ProjectReference.

When a ProjectReference specifies ReferenceOutputAssembly=false, it is explicitly stating that the referenced project's output assembly should not be included in ReferencePath. However, for the purposes of populating the Dependencies tree, we still wish to know that this item was present. Its absense from the ResolvedProjectReference item group results in a yellow triangle appearing on the reference in the tree.

To fix this, we override the target used by the ResolvedProjectReference rule to also return ProjectReference items having ReferenceOutputAssembly=false.

Fixes dotnet#2928

Co-authored-by: David Kean <davkean@microsoft.com>
@drewnoakes drewnoakes modified the milestones: 16.9, 16.8 Aug 21, 2020
@ghost ghost added the Resolution-Fixed The bug has been fixed, refer to the milestone to see in which release it was fixed. label Aug 23, 2020
@drewnoakes
Copy link
Member

A fix for this issue has been merged and will be released as part of 16.8.

@drewnoakes drewnoakes removed the Bug label Oct 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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. Triage-Approved Reviewed and prioritized
Projects
None yet
Development

Successfully merging a pull request may close this issue.