Why does adding an "imports" to project.json break this?

Question

Using Visual Studio 2015 update 3, I create a portable class library. Then I switch it to target .NET Standard.

So the project.json file looks basically like this:

"dependencies": {
  "Microsoft.NETCore.Portable.Compatibility": "1.0.1",
  "NETStandard.Library": "1.6.1"
},
"frameworks": {
  "netstandard1.3": {
  }
}

In the Class1.cs that was created, I add a simple method which uses the Any() method from Linq:

static void foo()
{
    var x = new string[] { "hello", "world", };
    var q = x.Any(s => s.Contains("m"));
}

And everything builds fine.

Now, I want this library to be able to reference a nuget package with a PCL profile, i.e. one that has not been updated to netstandard. My understanding is that I need to use an "imports" section in the "frameworks" section of the project.json file. So, I add this:

"frameworks": {
  "netstandard1.3": {
    "imports": ".NETPortable,Version=v4.6,Profile=Profile151"
  }
}

And make no other changes.

Now the build fails with:

Error CS1061 'string[]' does not contain a definition for 'Any' and no extension method 'Any' accepting a first argument of type 'string[]' could be found (are you missing a using directive or an assembly reference?)

It seems that simply by saying that we can accept a profile 151 PCL, the build has lost System.Linq.

Changing to netstandard 1.2 or 1.4 or 1.5 seems to make no difference.

Changing the "imports" value to other PCL profiles doesn't seem to matter.

Changing the "imports" value to the other form, something like "portable-net45+win8+wp8+wpa81", doesn't seem to matter.

Changing the "imports" value to "fubar" does result in an additional error about an invalid framework, as one might expect.

Anybody know why this happens?

Answer 1

I believe you need the imports to be in the form of portable-win8+wpa81+wp8+net45, etc. Not the full TFM as you have it spelled out. It also takes an array, so you can specify more than one.

Furthermore, while csproj + project.json is "supposed" to work in VS 2015, there may be bugs....that won't get fixed.

I'd strongly recommend using the latest VS 2017 RC and create a new .NET Standard Class Library. Then you can use <PackageTargetFallback> to specify the fallback TFM's you need (separated by a ;)