Sdk: Tools built with imports fail

[bricelam]

I have a tool (dotnet-ef) that depends on Ix-Async (a portable-windows8+net45+wp8 library). Its project.json looks like this.

{
  "compilationOptions": {
    "emitEntryPoint": true
  },
  "dependencies": {
    "Ix-Async": "1.2.5",
    "NETStandard.Library": "1.0.0-*"
  },
  "frameworks": {
    "dnxcore50": {
      "imports": "portable-net452+win81"
    }
  }
}

I'm trying to use that tool in a project with the following.

{
  "tools": {
    "dotnet-ef": "1.0.0-*"
  },
  "dependencies": {
    "NETStandard.Library": "1.0.0-*"
  },
  "frameworks": {
    "dotnet54": { }
  }
}

However running dotnet restore fails because the imports information used when building the tool is lost.

Restoring Tool 'dotnet-ef' for 'MyApp\obj\cb47a3d7-fd7d-48de-bda3-f29662e98d51\bin\project.json' in 'MyApp\obj\cb47a3d7-fd7d-48de-bda3-f29662e98d51\bin'
info : Restoring packages for MyApp\obj\cb47a3d7-fd7d-48de-bda3-f29662e98d51\bin\project.json...
error: Ix-Async 1.2.5 is not compatible with DNXCore,Version=v5.0.
error: Some packages are not compatible with DNXCore,Version=v5.0.
error: Ix-Async 1.2.5 is not compatible with DNXCore,Version=v5.0 (win7-x64).
error: Some packages are not compatible with DNXCore,Version=v5.0 (win7-x64).
error: Ix-Async 1.2.5 is not compatible with DNXCore,Version=v5.0 (win7-x86).
error: Some packages are not compatible with DNXCore,Version=v5.0 (win7-x86).
info : Committing restore...
info : Restore failed in 9329ms.

Note, this is also happening for Remotion.Linq (a portable-net45+win+wpa81+wp80 library).

[muratg]

@moozzyk this could be potentially blocking you as well.

[moozzyk]

Yes, I will check this today.

[davidfowl]

The proper way to fix this would be to package the project.json file

[victorhurdugaci]

We should probably do something similar to what dnu pack did for global tools.

[muratg]

@piotrpMSFT

Could we get this triaged?

[TheRealPiotrP]

@brthor is taking a look this morning.

[brthor]

@davidfowl I don't think packaging the project.json will help here.

It presents somewhat of a chicken vs. the egg problem. How can we restore that project.json if we can't restore the package which contains the project.json in the first place? We would need some type of meta package which gets restored first that has the project.json we actually want to restore.

I propose that we propagate the "imports" node from the project.json which contains the "tools" node to the generated project.json for the tool. This will give us a quick way to get this unblocked.

[brthor]

Talked with @victorhurdugaci and propagating the imports statements presents some issues if the tool has different imports than the app which is using it.

Does anyone know if we can have more than one imports statement?

[bricelam]

@brthor It looks like JSON arrays are supported by NuGet.

{
  "frameworks": {
    "netstandard1.3": {
      "imports": [
        "dotnet5.4",
        "portable-net452+win81"
      ]
    }
  }
}

[brthor]

Nice thanks Brice :+1:

[joshcomley]

In case anybody needs it, I bodged a console app to use the latest sources to generate migrations anyway. Details here:

http://overengineer.net/generating-new-entity-framework-migrations-when-dotnet-ef-is-broken

[bricelam]

Did this regress with portable app tools? I'm getting the following exception after our latest CLI update.

Could not load file or assembly 'Remotion.Linq, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=fee00910d6e5f53b' or one of its dependencies. The system cannot find the file
specified.

[brthor]

cc @joelverhagen @emgarten

This did not regress but the decision was made that tool consumers need to declare the imports.
See dotnet/cli#2214 for an example.

[bricelam]

Oh that's right. Sorry, I forgot.

[victorhurdugaci]

@brthor can you give more details about that reasoning behind that decision? I'm just curious why the app needs to know about the import statement that tools need. Also, I'm curious if a dotnet451 only app could use netstandardapp1.5 only tool.

[brthor]

@victorhurdugaci, @emgarten could give the best reasoning here. The basis of the decision was that imports are non ideal in the nuget world.

Project Tools ("tools" node) are completely independent apps from the consuming project, so the target framework of the consuming app should have no effect on whether you can run a specific tool (Project Dependencies tool are a different story here).

[emgarten]

@victorhurdugaci tools are restored for the target framework they are going to run under, the process that runs tools for dotnet will use netstandardapp1.5. This isn't in the project.json file because it cannot be changed.

Imports is considered a workaround to allow packages that haven't updated to netstandard yet. It needs to be added to project.json so that users opt into this instead of getting it by default, if it were to be the default then NuGet would never be able to remove this fallback behavior.

[bricelam]

BTW, I've mitigated EF's need to use imports for tools in aspnet/EntityFramework#4977 by removing nearly all of our tool's dependencies.