Question

我正在开发一个开源库，主要包含一个针对.NET Standard 2.0的类库项目。最重要的是，我还实现了一个控制台应用程序，它是该库的CLI。控制台项目（出于历史原因）仅针对.NET Framework 4.6.2。

现在我想知道为社区提供此控制台应用程序的最佳做法是什么。在最广泛的层面上，我看到两种可能性：

将控制台应用程序作为单独的NuGet发送。
将控制台应用程序发送到与类库相同的NuGet中，因为它只是一个次要的附加组件，并不能证明自己的软件包是合理的。

从历史上看，我一直在使用第二种方法，但考虑到类库可用于多目标场景，我不再确定了。也许将NuGet中的控制台应用程序分离出来更加清晰，以便它对完整.NET框架的依赖是明确的。

无论哪种方式，我都想知道控制台exe在NuGet的文件结构中所属的位置。从历史上看，我一直把它放在tools\net462下，但对this page上tools文件夹的评论让我感到不安全：

可从Package Manager控制台访问的Powershell脚本和程序

我不一定想象有人使用Package Manager Consoler中的CLI。相反，它将被用作独立的exe某处是一些shell。

Answer 1

Ther是一种似乎符合您需求的解决方案。您可以为dotnet工具创建命令行扩展。与dotnet ef类似，您可以创建dotnet myAwesomeTool命令。您需要做的唯一事情是以下：

创建一个控制台应用程序并将以下代码添加到.csproj

<PackageId>Company.MyAwesomeTool</PackageId>
<AssemblyName>dotnet-myAwesomeTool</AssemblyName>
<PackageType>DotnetCliTool</PackageType>
<GeneratePackageOnBuild>True</GeneratePackageOnBuild>

构建解决方案，您将在bin文件夹中找到nuget包。可以分发此nuget包，当您安装它时，可以在安装nuget的项目中运行dotnet myAwesomeTool。像我的魅力一样工作=）

要在其他项目上安装它，请将其添加到csproj：

<ItemGroup>
  <PackageReference Include="company.MyAwesomeTool" Version="1.0.0" />
</ItemGroup>
<ItemGroup>
  <DotNetCliToolReference Include="company.MyAwesomeTool" Version="1.0.0" />
</ItemGroup>

更多信息： https://blog.maartenballiauw.be/post/2017/04/10/extending-dotnet-cli-with-custom-tools.html

Answer 2

一般情况下，NuGet is meant only for delivering class libraries（请注意措辞＆＃34;如果您的图书馆......＆＃34;）。

使用Chocolatey代替将命令行和GUI应用程序部署到Windows。它有一个CLI，可用于轻松安装和更新应用程序。它是不 #include <stdio.h> int main() { int i = 97, *p = &i; foo(&i); printf("%d ", *p); } void foo(int *p) { int j = 2; p = &j; printf("%d ", *p); }，但使用类似的方法来打包和部署应用。

还有包管理器可以定位其他平台：

apt-get（对于Debian / Ubuntu / Mint）
Brew（适用于MacOS）
RPM（适用于Fedora / Red Hat）

注意：正如Martin Ullrich在评论中指出的那样，现在有一个way to deploy build tool CLIs with NuGet，主要用于持续集成部署方案。

在NuGet中包含控制台应用程序的最佳实践

2 个答案: