Support for DotNet tools

[sebastianslutzky]

Hi,
In my organisation, internal tools are created as .Net tools.
But we also use Chocolatey Enterprise for hosting, pushing and monitoring software from individual PCs.
At the moment, both systems (Choco & dotnet tools) are completely separate and unaware of each other. Are there plans for chocolatey to embrace dotnet tools and create some way of managing them without the need of repackaging tools as choco packages?

[gep13]

@sebastianslutzky thanks for reaching out about this!

Can you elaborate on exactly what sort of integration you would be looking for here? Are you thinking in terms of another additional source for Chocolatey, similar to what there is for Windows Features, or Ruby packages?

[danhaywood]

Hi @gep13 , I work with Seb and we were just discussing how to answer your question best.

As we see it, we have two similar packaging formats (both ultimately .nupkg files), and two different clients (choco install or dotnet tool install), and there are two different registries of what is installed on the PC (choco list --local-only or dotnet tool list --local). We see that C4B perhaps beats dotnet tool for discoverability - eg chocolatey GUI - and certainly for management, thanks to Chocolatey Central Manager (CCM).

Still, there's a lot of overlap in the features. In an ideal world (which we don't think is possible), we could imagine a single .nupkg available on some feed, that could be installed using either choco install or dotnet tool install, and - whichever tool was used to install the package - would also report as being installed using the other. For example, if I were to do "choco install myapp", then "dotnet tool list --local" would list it. Or, if I installed it using "dotnet tool install myapp", then "choco list --local-only" would list it.

As I say, we don't think that's possible (is it?) Instead, [A] we are thinking that maybe choco is the recommended way that we deploy dotnet tools, so that in our CI we package up a dotnet tool and then repackage it (somehow) also as a choco package. We would then tell folks to install using "choco install myapp", and in its ChocolateyInstall.ps1 it would just run "dotnet tool install myapp ". With this approach, the dotnet tool would be pushed to its nuget feed, and then the choco package would be pushed to its nuget feed.

An alternative idea [B] we had was that our CI would build and package up the dotnet tool, but then _rather than pushing it to its own feed, we would then create a choco package that embedded the dotnet tool as a .nupkg. In other words, the choco .nupkg would include the dotnet tool .nupkg, and only the choco package would be pushed to a feed. On install, the ChocolateyInstall.ps1 would effectively run "dotnet tool install myapp", specifying the source feed as the local directory somehow (a bit like "choco install xxx -s ." ).

A third thought we had [C] was that perhaps we don't create a choco package at all, instead just publish a dotnet tool package, but then the "choco sync" command (https://docs.chocolatey.org/en-us/choco/commands/synchronize) could be extended. In other words, it would run something like "dotnet tool list --local" and dynamically create choco packages for each of those dotnet tools listed.

Anyway, hope those thoughts make sense. Which approach of [A] or [B] do you recommend? Or might [C] be a consideration?

[gep13]

Before going too much further, just a quick clarification... You mentioned

dotnet tool list --local

Are you actually installing these dotnet tools to a local folder, or are you installing them globally on your machine?

Chocolatey does have the concept of alternative sources (https://docs.chocolatey.org/en-us/choco/commands/list#alternative-sources) where you could do something like choco list --source=webpi. This would allow Chocolatey to return a list of all the packages that have been installed through the Web Platform Installer. I could imagine a similar situation for packages that are installed via dotnet tool. Taking this further, I could see something like choco install myapp --source=dotnettools which would then use Chocolatey to install the dotnet tool package. Would this type of system be of interest?

Option C is an interesting one, and potentially not one that would be limited to only dotnet tool installations. This would be "similar" to the approach mentioned above, with the added benefit of not having to do any additional options on the choco list command to get information about what is installed on the system.

Of the other two options, A and B, personally, I would be going down the route of option B. This is due to the fact that the Chocolatey package that would be created would be self-contained, meaning that it would have everything that would be needed to perform the installation operation. All assets would be pushed to a single feed, as a single package, ready for installation.

[danhaywood]

Hi Gary,

To your question ... small mistake on my side... we actually only install these tools globally.

Based on your advice, for now we will go with option [B], thanks for that.

That said, extending the "alternative source" concept to support "dotnettools" sounds like a great solution. Or, choco sync also would work well, we think. You are probably in a better position to evaluate which is the better feature to implement. But would you like me to raise a ticket for this idea, referencing back to this discussion?

Thx