Runtime: Referencing Microsoft.NETCore.App 1.2.0-* results in type ambiguity

Created on 5 Dec 2016 · 21Comments · Source: dotnet/runtime

I was attempting to upgrade AspNetCore packages to 1.2.0-* M.NETCore.App \ 4.4.0-* CoreFx packages. However it looks like the Task type is brought in separately by both System.Runtime and System.Threading.Tasks package. Consequently an app that references Task fails:

{
  "frameworks": {
    "netcoreapp1.1": {
      "dependencies": {
        "Microsoft.NETCore.App": {
          "type": "platform",
          "version": "1.2.0-*"
        }
      }
    }
  }
}

```C#
using System;
using System.Threading.Tasks;

namespace ConsoleApplication
{
public class Program
{
public static Task Test() => Task.FromResult(0);
}
}
```
error CS0433: The type 'Task' exists in both 'System.Threading.Tasks, Version=4.0.10.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' and 'System.Runtime, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a

area-Infrastructure-libraries

Source

pranavkm

Most helpful comment

I think we made a fundamental mistake remapping netcoreapp1.1 to netstandard1.7 (for exactly this reason). What we should have done instead is keep netcoreapp1.1 and netcoreapp1.0 mapped to netstandard 1.6 and mapped netcoreapp1.2 to netstandard1.7. This would have kept everything working as is and would have allowed us to take new bits without grabbing a new CLI.

Remapping TFMs changes the restore outcome for projects using an older toolchain and I think that's broken. They should be immutable.

davidfowl on 7 Dec 2016

👍2

All 21 comments

cc @ericstj \ @davidfowl

pranavkm on 5 Dec 2016

Works for me. I suspect your restore client doesn't understand netcoreapp1.1 => netstandard1.7

ericstj on 5 Dec 2016

I'm using the 1.1.0 CLI:

.NET Command Line Tools (1.0.0-preview2-1-003177)

Product Information:
 Version:            1.0.0-preview2-1-003177
 Commit SHA-1 hash:  a2df9c2576

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.14393
 OS Platform: Windows
 RID:         win10-x64

Do you know what version of the CLI is meant to work here?

pranavkm on 5 Dec 2016

👍1

Newer than that. preview2-003121 worked for me. /cc @piotrpMSFT @weshaggard

ericstj on 5 Dec 2016

Can conform, this is broken with older builds.

1.0.0-preview2-003121 - Broken
1.0.0-preview2-003131 - Broken
1.0.0-preview2-1-003177 - Broken

davidfowl on 6 Dec 2016

@ericstj What version of nuget understands that mapping?

davidfowl on 6 Dec 2016

3.5.0 RC I believe. https://github.com/NuGet/NuGet.Client/commit/62aac7df1f4e67b3cb099bc6fc48abc1c8bb3f3a /cc @joelverhagen

ericstj on 6 Dec 2016

That's strange, I would have thought the latest CLI would have that. If not, xproj is kinda hosed...

/cc @piotrpMSFT @livarcocc

davidfowl on 6 Dec 2016

Correct, netcoreapp1.1 and netstandard1.7 mappings were added in 3.5.0-rc1. preview2 CLI has the older 3.5.0-beta2 (source).

That's strange, I would have thought the latest CLI would have that. If not, xproj is kinda hosed...

We have not bumped the NuGet version in the 1.0.0-preview2-* CLI train since preview2 was originally released. Is this something CLI or NuGet team should investigate doing?

/cc @rrelyea

joelverhagen on 6 Dec 2016

Isn't there a newer build of CLI post preview2 that has the update?

ericstj on 6 Dec 2016

Let me start a thread on the CLI since this clearly isn't a packaging issue.

pranavkm on 6 Dec 2016

Follow up here - https://github.com/dotnet/cli/issues/4946

pranavkm on 6 Dec 2016

I don't agree it's a CLI issue. I'm convinced it's a packaging issue.

davidfowl on 7 Dec 2016

@davidfowl, can you elaborate on how this is a packaging issue? We're intentionally putting things in netcoreapp1.1/netstandard1.7 right now as a placeholder for v.Next. If your intent is to consume packages from master then you need to have NuGet 3.5-RC or later and "netcoreapp1.1" actually means "netcoreappvNext".

If your intent is to actually target netcoreapp1.1 then you shouldn't be using packages from master. Use the 4.3.0 packages from the 1.1 release branch.

ericstj on 7 Dec 2016

Remapping TFMs changes the restore outcome for projects using an older toolchain and I think that's broken. They should be immutable.

davidfowl on 7 Dec 2016

👍2

If your intent is to consume packages from master then you need to have NuGet 3.5-RC or later and "netcoreapp1.1" actually means "netcoreappvNext".

That's not right. We shipped Microsoft.NETCore.App 1.1.0 which maps directly to netcoreapp1.1, it cannot mean vnext. That's netcoreapp1.2

davidfowl on 7 Dec 2016

@davidfowl The mapping of netcoreapp1.1 to nestandard1.7 was not a change. It was made before netcoreapp1.1 shipped and was what we intended to ship with netcoreapp1.1.

What changed was folks decided that we should stop letting netcore and desktop drive the definition of new NETStandard versions. As a result we decided to not use the 1.1 > 1.7 mapping as part of the 1.1 release.

Meanwhile, we asked Nuget for a mapping for vNext but schedules don't align to make that happen. So that work was delayed. In the interim we very intentionally used nca1.1 and ns1.7 as a placeholder. We had to have somewhere to put the new netstandard API and we had to have that be mapped by nuget. In the next month or so we should have tooling that enables the new TFMs (netcoreapp1.2 and netstandard2.0) but even that would require some hacking if you want it to work with XProj.

Bottom line is that if you want things to work with XProj and get the new API you'll need to cobble something together. I think @pranavkm has the right strategy of building a private. In corefx we do something similar, by patching CLI with an updated NuGet.Frameworks.dll. It's true that this private CLI will treat netcoreapp1.1 as actually VNext when using the latest packages. That's intentional right now and the work to update the packages is planned for the next month and happening in dev/eng.

ericstj on 7 Dec 2016

I'm "suddenly" getting this on my project (without changing any referenced packages, versions) - though I'm referencing NETCore.App 1.1.0, not 1.2.0:
The type 'Task<TResult>' exists in both 'System.Threading.Tasks, Version=4.0.10.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' and 'System.Runtime, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
What is the best thing I can do to either 1) Help with this issue, or 2) Diagnose/understand how to fix this myself, please?
Edit: Ok, I'm on 1.0.0-preview2-003133 and that's an "older" build. I can try updating, although I had other issues with the newer preview versions. Why would this "suddenly" start happening?