Is there an equivalent of DotNetCliToolReference that uses a solution-local project? #5189

Closed
fearthecowboy opened this Issue Jan 3, 2017 · 5 comments

Comments

Projects
None yet
5 participants
@fearthecowboy

Steps to reproduce

I have a solution that has many projects in it, one of which is a tool that I'd like to use with DotNetCliToolReference . Using DotNetCliToolReference to reference a tool in the same solution doesn't seem to be supported.

Expected behavior

In the same way that ProjectReference can be used instead of PackageReference, I would have hoped that there was an equivalent feature for a tool.

Actual behavior

I'm forced to build a package for the tool first, place it in a package repository (folder) and then reference the package.

@krwq

This comment has been minimized.

Show comment
Hide comment
@krwq

krwq Jan 3, 2017

Member

@fearthecowboy, I don't believe we support this directly but as a workaround you can do following:

  • this is assuming you got following directory structure:
    • ./ (root)
    • ./yourprojectwithdepontool/ (you want to add NuGet.Config here)
    • ./yourtool/
    • ./mynugetcache/ (directory which will get created by dotnet pack)
  • in the tool project directory run dotnet pack -o ../mynugetcache
  • in the project you want to reference the tool add a NuGet.Config (or edit existing) with following content:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="test-packages" value="../mynugetcache" />
  </packageSources>
</configuration>

Please let me know if this is not satisfactory workaround or any problems you may encounter

Member

krwq commented Jan 3, 2017

@fearthecowboy, I don't believe we support this directly but as a workaround you can do following:

  • this is assuming you got following directory structure:
    • ./ (root)
    • ./yourprojectwithdepontool/ (you want to add NuGet.Config here)
    • ./yourtool/
    • ./mynugetcache/ (directory which will get created by dotnet pack)
  • in the tool project directory run dotnet pack -o ../mynugetcache
  • in the project you want to reference the tool add a NuGet.Config (or edit existing) with following content:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="test-packages" value="../mynugetcache" />
  </packageSources>
</configuration>

Please let me know if this is not satisfactory workaround or any problems you may encounter

@natemcmaster

This comment has been minimized.

Show comment
Hide comment
Member

natemcmaster commented Jan 3, 2017

@fearthecowboy

This comment has been minimized.

Show comment
Hide comment
@fearthecowboy

fearthecowboy Jan 4, 2017

I ended up doing something similar, but wasn't thrilled with that so I made a .proj file that gets included by the appropriate consuming projects that has an InitialTargets that points to a target that

  • has a condition that only happens during dotnet restore and the tool isn't installed Condition="$(RestoreRecursive) AND !Exists('$(USERPROFILE)/.nuget/packages/.tools/dotnet-razor')
  • If it's not, it ensures the tools project gets built and installed before the dotnet restore continues

https://github.com/fearthecowboy/autorest/blob/coreclr/src/common/compile-cshtml.proj

fearthecowboy commented Jan 4, 2017

I ended up doing something similar, but wasn't thrilled with that so I made a .proj file that gets included by the appropriate consuming projects that has an InitialTargets that points to a target that

  • has a condition that only happens during dotnet restore and the tool isn't installed Condition="$(RestoreRecursive) AND !Exists('$(USERPROFILE)/.nuget/packages/.tools/dotnet-razor')
  • If it's not, it ensures the tools project gets built and installed before the dotnet restore continues

https://github.com/fearthecowboy/autorest/blob/coreclr/src/common/compile-cshtml.proj

@TheRealPiotrP

This comment has been minimized.

Show comment
Hide comment
@TheRealPiotrP

TheRealPiotrP Jan 5, 2017

Collaborator

Let's continue tracking this at NuGet/Home#2469

Collaborator

TheRealPiotrP commented Jan 5, 2017

Let's continue tracking this at NuGet/Home#2469

@KallDrexx

This comment has been minimized.

Show comment
Hide comment
@KallDrexx

KallDrexx Nov 20, 2017

@krwq The one issue I see with the local nuget method is that it's hard to test new versions. For example, if I make one change to my tool code I have to increment the version or clear nuget cache every single time.

@krwq The one issue I see with the local nuget method is that it's hard to test new versions. For example, if I make one change to my tool code I have to increment the version or clear nuget cache every single time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment