canopy icon indicating copy to clipboard operation
canopy copied to clipboard

Nuget Warning for canopy in .NET Core 2 Project

Open totano opened this issue 8 years ago • 13 comments

NU1701	
Package 'canopy 2.0.0' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETCoreApp,Version=v2.0'. This package may not be fully compatible with your project.

totano avatar Apr 13 '18 12:04 totano

Does it still work? I have googled around and after reading the first page I haven't figured out how to fix it.

lefthandedgoat avatar Apr 13 '18 20:04 lefthandedgoat

I made a new .net core app and can repro it, but im having a hard time figuring out what the do to fix it. I will try a few things

lefthandedgoat avatar Apr 13 '18 22:04 lefthandedgoat

yes, it is just a warning

totano avatar Apr 14 '18 03:04 totano

Same here with Console Application (.NET Core 2.0): "Package 'canopy 2.0.1' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETCoreApp,Version=v2.0'. This package may not be fully compatible with your project."

netmajor avatar May 02 '18 09:05 netmajor

I have made a small research and found that when canopy package is created with dotnet pack then adding package to another project shows no warnings (works correct).

What I did:

git clone https://github.com/lefthandedgoat/canopy.git cd canopy dotnet restore dotnet build - to be sure, that it compiles dotnet pack --version-suffix 999 - to create unique version number

This showed some warnings, but the package has been created: c:\github\canopy\src\canopy\bin\Debug\canopy.1.0.0-999.nupkg

Then in my project file (MyProject.fsproj) I have added additional local nuget source section (c:\github\canopy\src\canopy\bin\Debug):

<PropertyGroup>
  <RestoreSources>
    $(RestoreSources); 
    C:\github\canopy\src\canopy\bin\Debug; 
    https://api.nuget.org/v3/index.json
  </RestoreSources>
</PropertyGroup>

Then (still in my project):
dotnet add .\MyProject.fsproj package canopy --version 1.0.0-999

After that the package has been added to my project:

...
<ItemGroup>
    <PackageReference Include="Argu" Version="5.1.0" />
    <PackageReference Include="canopy" Version="1.0.0-999" />
  </ItemGroup> 
...

... and there were no warnings:

info : Adding PackageReference for package 'canopy' into project '.\MyProject.fsproj'. log : Restoring packages for C:\github\MyProject\MyProject.fsproj... info : CACHE https://api.nuget.org/v3-flatcontainer/fsharp.core/index.json info : Package 'canopy' is compatible with all the specified frameworks in project '.\MyProject.fsproj'. info : PackageReference for package 'canopy' version '1.0.0-999' added to file 'C:\github\MyProject\MyProject.fsproj'.

zbigniew-gajewski avatar May 02 '18 18:05 zbigniew-gajewski

@zbigniew-gajewski Thanks for the lead. I used paket pack to make these packages and it may have caused a difference. I am on vacation now but when I get home I will see if I can make a new package like you did that does not cause the warning.

Thanks again!

lefthandedgoat avatar May 02 '18 19:05 lefthandedgoat

This is actually a real issue.

It may just be a warning but it is killing the build on my TFS build server :-(

Apparently the canopy nuget file is specifying "<group targetFramework="netstandard2.0">" but it seems it should be: "<group targetFramework=".NETStandard2.0">"

The latter is taken from the Selenium.WebDriver which does not exhibit the issue.

Log file from the build server for Canopy: Checking compatibility for canopy 2.0.1 with .NETCoreApp,Version=v2.1. Package canopy 2.0.1 is not compatible with netcoreapp2.1 (.NETCoreApp,Version=v2.1). Package canopy 2.0.1 supports: net (.NETFramework,Version=v0.0)

Log file from the build server for Selenium.WebDriver: Checking compatibility for Selenium.WebDriver 3.14.0 with .NETCoreApp,Version=v2.1. Package Selenium.WebDriver 3.14.0 is not compatible with netcoreapp2.1 (.NETCoreApp,Version=v2.1). Package Selenium.WebDriver 3.14.0 supports:

  • net35 (.NETFramework,Version=v3.5)
  • net40 (.NETFramework,Version=v4.0)
  • net45 (.NETFramework,Version=v4.5)
  • netstandard2.0 (.NETStandard,Version=v2.0)

so obviously some translation between ".NETStandard2.0" to "netstandard2.0" is going on within nuget. It is likely a very simple fix. Pretty please ;-)

.net core 2.0 (and 2.1) would also be nice though not at all a requirement as Selenium doesn't either.

(note that I've build and tested this with .NETCore 2.0, 2.1 and .NET standard 2.0. It is all the same.

soerennielsen avatar Sep 09 '18 16:09 soerennielsen

Later today I have some free time and I will try switching to .NETStandard2.0 to see if that fixes it. Thanks!

lefthandedgoat avatar Sep 09 '18 16:09 lefthandedgoat

I think this will fix it for you. It was an epic journey to figure out the slightest thing to change.

https://www.nuget.org/packages/canopy/2.1.0

This line fixed it: https://github.com/lefthandedgoat/canopy/commit/9135bddf386ee61038a1f917101a7d2a9b590ff4#diff-beb5bdc57f593a54f2fcbbdd7ebc489aR21

Problem was that I was making these changes, building a new package and testing locally. VS was SO NICE TO ME and kept installed old cached versions of a package that did not work. I was only able to see any changes working by updating the package number so there was no caching. Hours.... it took lol.

Hope this fixes TFS for you!

lefthandedgoat avatar Sep 10 '18 04:09 lefthandedgoat

It works!

Sorry that you had to go the long way around it. I too have been burned by nuget packages in the past when I created a few.

it was the ".nuget" cache folder?

I tested: .NET standard 2.0 👍 .NET standard 2.1 👍 (defaulted fine back) .NET core 2.1: 👎 (defaulted to .net Framework).

The last one is not critical to me, as I can use .NET standard instead just fine. Just curious that it wouldn't default back to .NET standard.

THANK you.

soerennielsen avatar Sep 10 '18 11:09 soerennielsen

One final note:

Please be sure to use Nuget >=4.3.0 as that one will know that a .Net Core app can default back to use .Net standard packages. Had some fun with this as .NET Standard dll's cannot be executed within a docker container (it seems only VS will allow it).

I think that this issue can be closed now :-)

soerennielsen avatar Sep 13 '18 14:09 soerennielsen

Use Nuget 4.3.0 client?

lefthandedgoat avatar Sep 13 '18 15:09 lefthandedgoat

Yes, on the build server I had to add a little powershell script to download Nuget 4.3.0 and use that one.

On Desktop it was fine with a later version of VS 2017.

soerennielsen avatar Oct 13 '18 07:10 soerennielsen