Skip to content

Paket causes build warnings by adding references to NETStandard.Library #2852

Description

@yaakov-h

Description

When adding Paket to a project which either:

  • targets .NET Standard exclusively, or
  • multi-targets, and one of those targets is .NET Standard,

the project immediately gets two build warnings. In a strict environment, this fails the build.

Repro steps

Please provide the steps required to reproduce the problem

  1. Clone https://github.com/yaakov-h/PaketTargetFrameworkRepro
  2. Run dotnet restore
  3. Optionally, also run dotnet build.

Expected behavior

The build completes with zero warnings and zero errors.dotnet

Actual behavior

C:\Temp\PaketTargetFrameworkRepro>dotnet restore && dotnet build
C:\Program Files\dotnet\sdk\2.0.2\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Sdk.DefaultItems.targets(199,5): warning : A PackageReference for 'NETStandard.Library' was included in your project. This package is implicitly referenced by the .NET SDK and you do not typically need to reference it from your project. For more information, see https://aka.ms/sdkimplicitrefs [C:\Temp\PaketTargetFrameworkRepro\PaketTargetFrameworkRepro\PaketTargetFrameworkRepro.csproj]
C:\Program Files\dotnet\sdk\2.0.2\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Sdk.DefaultItems.targets(199,5): warning : A PackageReference for 'NETStandard.Library' was included in your project. This package is implicitly referenced by the .NET SDK and you do not typically need to reference it from your project. For more information, see https://aka.ms/sdkimplicitrefs [C:\Temp\PaketTargetFrameworkRepro\PaketTargetFrameworkRepro\PaketTargetFrameworkRepro.csproj]
  Restore completed in 16.34 ms for C:\Temp\PaketTargetFrameworkRepro\PaketTargetFrameworkRepro\PaketTargetFrameworkRepro.csproj.
C:\Program Files\dotnet\sdk\2.0.2\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Sdk.DefaultItems.targets(199,5): warning : A PackageReference for 'NETStandard.Library' was included in your project. This package is implicitly referenced by the .NET SDK and you do not typically need to reference it from your project. For more information, see https://aka.ms/sdkimplicitrefs [C:\Temp\PaketTargetFrameworkRepro\PaketTargetFrameworkRepro\PaketTargetFrameworkRepro.csproj]
C:\Program Files\dotnet\sdk\2.0.2\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Sdk.DefaultItems.targets(199,5): warning : A PackageReference for 'NETStandard.Library' was included in your project. This package is implicitly referenced by the .NET SDK and you do not typically need to reference it from your project. For more information, see https://aka.ms/sdkimplicitrefs [C:\Temp\PaketTargetFrameworkRepro\PaketTargetFrameworkRepro\PaketTargetFrameworkRepro.csproj]
Microsoft (R) Build Engine version 15.4.8.50001 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  PaketTargetFrameworkRepro -> C:\Temp\PaketTargetFrameworkRepro\PaketTargetFrameworkRepro\bin\Debug\netstandard1.3\PaketTargetFrameworkRepro.dll

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:00.62

C:\Temp\PaketTargetFrameworkRepro>

Known workarounds

  1. Target net and/or netcoreapp explicitly instead of netstandard, or
  2. Add <DisableImplicitFrameworkReferences>true</DisableImplicitFrameworkReferences> to the project file.

Additional Information

.NET Command Line Tools (2.0.2)

Product Information:
 Version:            2.0.2
 Commit SHA-1 hash:  a04b4bf512

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.15063
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.0.2\

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.0
  Build    : e8b8861ac7faf042c87a5c2f9f2d04c98b69f28d

Activity

  1. changed the title [-]Paket causes build warnings by adding implicit references to NETStandard.Library[/-] [+]Paket causes build warnings by adding references to NETStandard.Library[/+] on Oct 18, 2017
  2. forki commented on Oct 18, 2017

    @forki
    Member

    Looks like this is .NET Command Line Tools (2.0.2) behaviour.
    Will try to work around

  3. forki commented on Oct 18, 2017

    @forki
    Member

    BTW: you commited 8MB version of paket into the repro. Usually you want to commit the bootstrapper renamed as paket.exe. Then it's only couple of KB

  4. yaakov-h commented on Oct 18, 2017

    @yaakov-h
    ContributorAuthor

    Thanks!

    And yeah, I know. Simple dirty repro... didn't know you could rename the bootstrapper though, thanks for the tip.

  5. forki commented on Oct 18, 2017

    @forki
    Member
  6. forki commented on Oct 18, 2017

    @forki
    Member

    mhm for some reason this breaks VS integration. reverting for now

  7. reopened this on Oct 18, 2017
  8. forki commented on Oct 18, 2017

    @forki
    Member

    looks it wasn't the issue for broken VS integration

  9. yaakov-h commented on Oct 18, 2017

    @yaakov-h
    ContributorAuthor

    Wrong bisect?

  10. forki commented on Oct 18, 2017

    @forki
    Member

    no I don't really know yet. It's VS isn't really stable and therefore it's all manual testing..

  11. added a commit that references this issue on Oct 18, 2017
    90f63c5
  12. JohanLarsson commented on Feb 4, 2019

    @JohanLarsson
    Contributor

    This should still be open right?

  13. forki commented on Feb 4, 2019

    @forki
    Member

    I thought we fixed that in the targets file?

  14. 26 remaining items

  15. forki commented on Nov 21, 2019

    @forki
    Member
  16. BlythMeister commented on Nov 21, 2019

    @BlythMeister
    Contributor

    Sorry didn't notice your message.

    Good news, no errors & i can see the nowarn in my paket props file.
    Bad news, warning still shows in visual studio 🤦‍♂

  17. forki commented on Nov 21, 2019

    @forki
    Member

    can you please remove the obj folder and delete the paket-files folder so that we test against freshly created obj?

  18. forki commented on Nov 21, 2019

    @forki
    Member

    i can see the nowarn in my paket props file.

    didn't read that, So the nowarn did not help. can you please manually remove the condition from that property group?

  19. BlythMeister commented on Nov 21, 2019

    @BlythMeister
    Contributor

    adding <DisableImplicitFrameworkReferences>true</DisableImplicitFrameworkReferences> to my project file manually cleared the warning

    from https://github.com/dotnet/cli/issues/5346#issuecomment-276029481

  20. BlythMeister commented on Nov 21, 2019

    @BlythMeister
    Contributor

    the no warn also shows in the project properties
    image
    So it's being seen by Visual Studio....just ignored.

  21. BlythMeister commented on Nov 21, 2019

    @BlythMeister
    Contributor

    manually updating paket.props file to have

        <PropertyGroup Condition="($(DesignTimeBuild) == true)">
            <DisableImplicitFrameworkReferences>true</DisableImplicitFrameworkReferences>
        </PropertyGroup>
    

    stops the warning showing...

  22. forki commented on Nov 21, 2019

    @forki
    Member

    ok since it's only about designtime we can use that for now. In Paket 6 we will revisit how to deal with Implicit references. They are pretty bad from package management standpoint....

  23. forki commented on Nov 21, 2019

    @forki
    Member

    ok 5.236.5 is out now

  24. BlythMeister commented on Nov 21, 2019

    @BlythMeister
    Contributor

    Should the paket props version number be bumped?

  25. forki commented on Nov 21, 2019

    @forki
    Member
  26. BlythMeister commented on Nov 21, 2019

    @BlythMeister
    Contributor

    @forki that fixes some....but broke others...so i don't think having that property is a good idea :(

    My hunch....just reset this and leave the warning in Visual studio....it's not the end of the world...

  27. forki commented on Nov 21, 2019

    @forki
    Member

    ok let's close it with manual workaround in csproj for people that want to get rid of it:

    <PropertyGroup Condition="($(DesignTimeBuild) == true)">
        <DisableImplicitFrameworkReferences>true</DisableImplicitFrameworkReferences>
    </PropertyGroup>
    

    we will revisit it soonish

  28. BlythMeister commented on Nov 21, 2019

    @BlythMeister
    Contributor

    sounds like a good idea to me :)

  29. forki commented on Nov 21, 2019

    @forki
    Member

    5.236.6 is on it's way and should restore original behaviour

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions