Sdk: Unable to include project reference to CLI tool

[Antaris]

Steps to reproduce

Create two .NET Core projects

• Class library representing the tool (DemoTool)
  -- Add Program.cs with Main(string[] args) => Console.WriteLine("Hello World");

{
  "title": "Demo Tool",
  "version": "0.1.0-*",

  "buildOptions": {
    "emitEntryPoint": true,
    "outputName": "dotnet-demo-tool"
  },

  "dependencies": {
  },

  "frameworks": {
    "netcoreapp1.0": {
      "imports": "portable-net452+win81",
      "dependencies": {
        "Microsoft.NETCore.App": {
          "version": "1.0.0-rc2-3002702",
          "type": "platform"
        }
      }
    }
  }
}

• Console application representing the app (DemoApp) referencing the tool

Configure a project reference to the tool

{
  "title": "Demo Tool",
  "version": "0.1.0-*",

  "buildOptions": {
    "emitEntryPoint": true
  },

  "tools": {
    "DemoTool": {
      "version": "0.1.0-*"
    }
  }

  "frameworks": {
    "netcoreapp1.0": {
      "imports": "portable-net452+win81",
      "dependencies": {
        "Microsoft.NETCore.App": {
          "version": "1.0.0-rc2-3002702",
          "type": "platform"
        }
      }
    }
  }
}

Execute dotnet restore

Expected behavior

dotnet restore executes successfully.

dotnet demo-tool executes successfully and "Hello World" is written to the console output.

Actual behavior

dotnet restore fails:

Unable to resolve 'DemoTool (>= 0.1.0)' for '.NETCoreApp,Version=v1.0'.

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.0-preview1-002702)

Product Information:
 Version:     1.0.0-preview1-002702
 Commit Sha:  6cde21225e

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

[blackdwarf]

@Antaris have you used dotnet pack to package a tool as a NuGet package? Did you also point dotnet restore to the right feed where the tool is?

There is a document on http://dotnet.github.io/docs/core-concepts/core-sdk/cli/extensibility.html that goes into more details about how this all works.

[Antaris]

@blackdwarf

No, what I am trying to do is use a .NET Core CLI tool as a project reference, like I can do for a class library. The problem with the dotnet pack approach is that it requires me to pack and deploy an in-development tool through which I then have to reference in a _separate_ solution because I can't restore it using a local project source reference instead of it trying to download it from a package source.

Previously in DNX, I could express commands in a project.json file, and those commands could be projects in the same solution - I can't seem to get this to work for .NET Core CLI tools.

I realise the tooling is considered "Preview 1", but I can't find any information on debugging and using CLI tools in the same solution.

Any guidance would be much appreciated.

[GrantErickson]

I am running into the same issue.

I want to be able to debug my CLI tool like I was able to with DNX. Additionally, I was hoping for a quick turn around for debugging my code gen templates. Creating a package and restoring every time I want to run after a change seems like a very slow process.

Any guidance on the debug story for tools?

[blackdwarf]

@Antaris @GrantErickson this is not supported for RC2. You have to package your tool as a Nuget package. However, you don't have to have a feed, you can restore it using the -f switch to dotnet restore.

We are thinking about whether to add this feature going forward.

[GrantErickson]

Thanks for the update. Good to know I can stop looking. I would definitely vote for a better debug story going forward.

[TheRealPiotrP]

@rrelyea enabling p2p tools will primarily be a NuGet feature. Should we track this in NuGet/home?

[aL3891]

There's this issue Nuget/Home#2469 and also dotnet/sdk#4800

[Antaris]

That's fair enough. I have a follow up question:

Given that I could be building a tool to use the output of a projects compile - how would I initialise DependencyModel.Default with the context of the project I am trying to target, if I am running my tool using dotnet run?

[alexandru-calinoiu]

I am trying to build a custom tool like this my project.json file is:

{
  "version": "1.0.0",
  "buildOptions": {
    "emitEntryPoint": true,
    "outputName": "dotnet-hello"
  },

  "frameworks": {
    "netcoreapp1.0": {
      "imports": "portable-net452+win81",
      "dependencies": {
        "Microsoft.NETCore.App": {
          "version": "1.0.0-rc2-3002702",
          "type": "platform"
        }
      }
    }
  }
}

I package it, but when I try to restore it I get:

 Package dotnet-hello 1.0.0 is not compatible with netcoreapp1.0 (.NETCoreApp,Version=v1.0). Package dotnet-hello 1.0.0 supports: net451 (.NETFramework,Version=v4.5.1)
    One or more packages are incompatible with .NETCoreApp,Version=v1.0.
    Project dotnet-hello is not compatible with net451 (.NETFramework,Version=v4.5.1). Project dotnet-hello supports: netcoreapp1.0 (.NETCoreApp,Version=v1.0)
    One or more projects are incompatible with .NETFramework,Version=v4.5.1.

The package.json for the current project is:

{
  "version": "1.0.0",
  "packOptions": {
    "tags": [ "" ],
    "projectUrl": "",
    "licenseUrl": ""
  },
"dependencies": {
    "dotnet-hello": "1.0.0-*"
  },
  "frameworks": {
    "net451": {
      "dependencies": {
      }
    }
  },
  "tools": {
    "dotnet-hello": {
      "version": "1.0.0-*",
      "imports": [
        "portable-net45+win8",
        "dnxcore50"
      ]
    }
  }
}

[brthor]

@alexandru-calinoiu

You have in issue there in that the project.json has a dependency on dotnet-hello but targets net451 while dotnet-hello targets netcoreapp1.0.

To resolve this you can either add net451 to the dotnet-hello project.json or remove it as a dependency from the consuming project.json. Having it both as a dependency and a tool is not required for using it as a tool. Putting it in the tools node is sufficient.

[pauldotknopf]

I am suprised there isn't currently a debug story for tools in dotnet-cli preview1. How does the ASP.NET and .NET teams develop their tools? Like, the user-secrets, and iis tooling? Do you dotnet pack & dotnet restore for every code change?

[brthor]

currently yes, we have set up infrastructure to run automated tests this way.

This is on the radar though.

[liamdawson]

Risking a plug here, but you might find this helpful when trying to write/debug tools (or anything that benefits from a local auto-refreshing nuget feed). Feedback/contributions welcome.

https://github.com/liamdawson/DotNet.DevFeed/

[BrainCrumbz]

@liamdawson read about usage, but it's not really clear how does one take advantage of that. Could you please explain how to use such tool in a typical tool development cycle on local dev machine:

tool edit -> tool build -> tool pack -> ??? -> client restore -> client build -> dotnet tool client\project\dir

Thanks!

[liamdawson]

@BrainCrumbz in order not to litter this issue with unrelated comments, I've moved that discussion to an issue on my repo: https://github.com/liamdawson/DotNet.DevFeed/issues/4

[TheRealPiotrP]

Cool. Since this is a project.json issue i'm going to go ahead and close it.

[Antaris]

You say it's a project.json issue but with the migration back to MSBuikd, what is the correct approach we should be using for referencing projects as CLI tools. The workflow has to be simple and setting up a feed, packing and publishing for each change is the complete opposite of that. How can I step in to a debugging session? Etc...

[TheRealPiotrP]

@Antaris the workflow in csproj is the same as it was in project.json. We didn't have time to improve the developer experience for these extensions in 1.0.0 but will likely make some steps for 2.0. There are several avenues we need to explore including:

• Guidance for using tools vs. MSBuild Tasks
• Project-specific tools vs. global tools
• Developer experiences for tools & tasks

As you point out, the current experience is quite lackluster. I think that we can do some short-term tricks to make this better [define a solution-level packages directory, set the tools project to Pack on Build, and use MSBuild properties to get the consuming project to restore this pack output], I'd like for the team to wrap up 1.0 and really think through how this experience should be expressed without hacks.

If you're interested in pursuing a short-term approach like what I called out above, I'd be happy to help figure out how to wire it up.