Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

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

Comments

@fearthecowboy
Copy link

@fearthecowboy fearthecowboy commented Jan 3, 2017

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
Copy link
Member

@krwq 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
Copy link
Contributor

@natemcmaster natemcmaster commented Jan 3, 2017

@fearthecowboy
Copy link
Author

@fearthecowboy 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
Copy link
Contributor

@TheRealPiotrP TheRealPiotrP commented Jan 5, 2017

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

@KallDrexx
Copy link

@KallDrexx KallDrexx commented 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.

@msftgits msftgits transferred this issue from dotnet/cli Jan 31, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.