Home: Support AssetTargetFallback for DotNetCliToolReference

[livarcocc]

_From @tmds on June 9, 2017 12:38_

Steps to reproduce

lib/lib.csproj

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <GeneratePackageOnBuild>True</GeneratePackageOnBuild>
    <PackageType>DotnetCliTool</PackageType>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.Composition" Version="1.0.30" />
  </ItemGroup>
</Project>

app/app.csproj

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <DotNetCliToolReference Include="lib" Version="1.0.0"/>
  </ItemGroup>
</Project>

app/NuGet.Config

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="test" value="../lib/bin/Debug" />
  </packageSources>
  <activePackageSource>
    <add key="test" value="../lib/bin/Debug" />
  </activePackageSource>
</configuration>

$ dotnet restore lib
$ dotnet build lib
$ dotnet restore app



md5-c913c717cb86a5940d9c637712c0910f



/opt/dotnet/sdk/2.0.0-preview1-005977/NuGet.targets(97,5): error : Package Microsoft.Composition 1.0.27 is not compatible with netcoreapp2.0 (.NETCoreApp,Version=v2.0). Package Microsoft.Composition 1.0.27 supports: portable-net45+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=Profile259) [/tmp/repro/app/app.csproj]
/opt/dotnet/sdk/2.0.0-preview1-005977/NuGet.targets(97,5): error : One or more packages are incompatible with .NETCoreApp,Version=v2.0. [/tmp/repro/app/app.csproj]

Note: Replacing DotNetCliToolReference with PackageReference causes the app to restore fine.

Environment data

2.0.0-preview1-005977

_Copied from original issue: dotnet/cli#6814_

[tmds]

@emgarten ptal

[emgarten]

Projects allow netcoreapp2.0 to bring in older desktop compatible packages. Tools do not currently allow this, they must be netcoreapp/netstandard.

Microsoft.Composition 1.3.0 contains lib/portable-net45+win8.. which is not compatible with netcoreapp.

@ericstj is MEF going to be updated to support netstandard?

[dasMulli]

Looks like the problem is that a cli tool can be built against netcoreapp2.0 because the SDK defines the assets target fallback, but it cannot be consumed because this fallback is not applied while restoring the tool?
It's unfortunate that you'd have to know to set DisableImplicitAssetTargetFallback to false in the tool's csproj to detect these errors early on. (DisableImplicitPackageTargetFallback in preview1)

[tmds]

Can we have the same restore behavior for DotNetCliToolReference references as we have for PackageReferences?

[emgarten]

Can we have the same restore behavior for DotNetCliToolReference references as we have for PackageReferences?

This could be done, AssetTargetFallback to net461 makes more sense for tools now that it is on by default.

I think the fix for this specific issue is that Microsoft.Composition needs to support netstandard2.0 without requiring the fallback. This package has come up several times as a pain point and that has been the conclusion each time.

[tmds]

@emgarten can we use this issue for updating the restore behavior of DotNetCliToolReference so it matches with PackageReference? Is there an appropriate repo to create an issue for Microsoft.Composition?

[emgarten]

@tmds it looks like Microsoft.Composition has moved to System.Composition which supports netstandard. Could you try that package? For reference: https://github.com/dotnet/corefx/issues/14653

I've updated the title of this issue to track AssetTargetFallback support for tools. The open question there is: Should users be able to turn ATF on/off for tool restores and set the framework, or should NuGet always apply the default of net461.

[tmds]

I'm not using Microsoft.Composition directly, I use the Roslyn https://www.nuget.org/packages/Microsoft.CodeAnalysis.Workspaces.Common/ package.
Is "PackageReference" also using "net461"?

[emgarten]

I use the Roslyn https://www.nuget.org/packages/Microsoft.CodeAnalysis.Workspaces.Common/ package.

Oh I see. This might be hard to work around then without falling back.

With PackageReference it reads AssetTargetFallback from the project file and adds additional compatibility. Tool restores are unrelated to the project framework/fallback so this can't just be applied to tools in the project.

There would need to be a way to define this on the tool reference, or NuGet would need to just apply the fallback when it sees a tool restore for netcoreapp2.0.

[tmds]

NuGet would need to just apply the fallback when it sees a tool restore for netcoreapp2.0.

I think this is the preferable approach. A tool netcoreapp2.0 should be able to reference the same packages as a regular netcoreapp2.0.

[tmds]

@emgarten I hope this gets solved for .NET Core 2.0. I'm working on a tool that generates code using Roslyn and it would be a shame if it can't work due to not being able to restore packages.

[rrelyea]

Really don't want to open up this capability for Tools. We kept it restricted in V1 on purpose.
That said, want to help enable your scenario.

Would prefer to see Roslyn do the work to move over.

@jaredpar - when does Roslyn plan to enable NetStandard 2 versions of
Microsot.CodeAnalysis.Workspaces.Common?

[tmds]

This is considered a major feature of .NET Core 2.0. I don't understand why you'd want to restrict this for tools when it's available for apps.

[jaredpar]

when does Roslyn plan to enable NetStandard 2 versions of Microsot.CodeAnalysis.Workspaces.Common?

Are you asking when will the package target NetStandard 2 vs. the 1.3 it targets today? If so the answer is a long time. We don't plan on targeting NetStandard 2 anytime soon, dev16 at the earliest.

Note that we very recently moved our dependency from Microsoft.Compostition to System.Composition. This let us become a pure NetStandard package with no need for fallbacks.

[emgarten]

Note that we very recently moved our dependency from Microsoft.Compostition to System.Composition. This let us become a pure NetStandard package with no need for fallbacks.

I think @tmds only needs this change to avoid the extra fallback in restore to consume the portable- assets in Microsoft.Compostition. When will Roslyn packages be released on nuget.org that have the System.Composition dependency (or is there one already)?

[jaredpar]

When will Roslyn packages be released on nuget.org that have the System.Composition dependency (or is there one already)?

The latest is 2.3.0-beta1. That still uses Microsoft.Composition.

The 2.3.0-beta2 release will use System.Composition. That should be released soon. Will poke and ask why it's not up yet.

[jaredpar]

Note: another Roslyn developer corrected me. The commit which moved us from Microsoft.Composition to System.Composition did not make the 15.3 Preview 2 release. It will not come around until Preview 3 (aka beta 3).

[tmds]

So, this will be part of .NET Core 2.0? Great! That helps me with my use-case.
I would expect some other people to hit this issue too for libraries that aren't on the verge of being migrated to netstandard.

[jaredpar]

@tmds

So, this will be part of .NET Core 2.0?

This Roslyn change is not tied to Net Core 2.0. Our package will be shipped with this change and continuing to target Net Standard 1.3. So it will be usable in Net Core 2.0 but also Net Core 1.1.

Am I missing a subtly here?

[tmds]

@jaredpar my mistake. When (roughly) do you think there will be a NuGet.org package that contains the commit?
Until then, this package can not be used as a dependency of a 2.0 cli tool.

[jaredpar]

@tmds

The packages with the changes are available now on our MyGet feed:

https://dotnet.myget.org/gallery/roslyn

Grab the latest 2.3.0-beta3-* package. This is the package that will eventually become our 2.3.0-beta3 package on NuGet.org.

As for when it will appear on NuGet.org I don't know the exact date. But it will come out at roughly the same time as 15.3 Preview 3.

[tmds]

@emgarten @rrelyea this issue can be closed. Using the 2.3.0-beta3 package works for me. Thanks.