在NuGet中包含控制台应用程序的最佳实践 [英] Best practice to include console app in NuGet

查看:303
本文介绍了在NuGet中包含控制台应用程序的最佳实践的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在开发一个开放源代码库,主要由一个针对.NET Standard 2.0的类库项目组成。最重要的是,我还实现了一个控制台应用程序,即该库的CLI。控制台项目(出于历史原因)仅针对.NET Framework 4.6.2。

I'm developing an open-source library which mainly consists of one class-library project targeting .NET Standard 2.0. On top of that, I've also implemented a console app which is the CLI to this library. The console project (for historic reasons) only targets .NET Framework 4.6.2.

现在,我想知道哪种最佳实践才能使该控制台应用程序可用于社区。从最广泛的角度来看,我看到两种可能性:

Now I wonder what would be the best practice in order to make this console app available to the community. On the broadest level, I see two possibilities:


  1. 将控制台应用程序作为单独的NuGet运送。

  2. 将控制台应用程序与类库放在同一NuGet上,因为它只是一个很小的附加组件,并不证明自己的软件包是正确的。

从历史上看,我一直在使用第二种方法,但是考虑到类库可以在多目标方案中使用,我不确定。也许将控制台应用程序以其自己的NuGet分开是比较干净的,这样就清楚了它对整个.NET框架的依赖。

Historically, I've been using the second approach but considering that the class library can be used in a multi-targeting scenario, I'm not sure anymore. Maybe it's cleaner to separate the console app in a NuGet of its own so that it's dependency on the full .NET framework is clear.

无论哪种方式,我都想知道控制台exe在哪里属于NuGet的文件结构。从历史上看,我一直将其放在 tools\net462 下,但对tools 文件夹的评论= https://docs.microsoft.com/zh-cn/nuget/create-packages/creating-a-package#from-a-convention-based-working-directory rel = nofollow noreferrer>此页面让我感到不安全:

Either way I wonder where the console exe belongs to in the file structure of the NuGet. Historically, I've been putting it under tools\net462 but a comment about the tools folder on this page made me insecure:


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

Powershell scripts and programs accessible from the Package Manager Console

我不一定想像有人从Package Manager控制台中使用CLI。而是在某些外壳的某个地方用作独立exe。

I'm not necessarily imagining someone using the CLI from the Package Manager Consoler. Rather it would be used as stand-alone exe somewhere is some shell.

推荐答案

通常, NuGet仅用于传递类库(请注意如果您的图书馆...这句话)。

In general, NuGet is meant only for delivering class libraries (note the wording "if your library...").

使用巧克力代替,用于将命令行和GUI应用程序部署到Windows。它具有一个CLI,可用于轻松安装和更新应用程序。它不是不是 NuGet ,而是使用类似的方法来打包和部署应用程序。

Use Chocolatey instead for deploying command-line and GUI apps to Windows. It has a CLI that can be used to easily install and update applications. It is not NuGet, but uses a similar method to package and deploy the app.

也有针对其他平台的软件包管理器:

There are also package managers to target other platforms:


  1. apt-get (对于Debian / Ubuntu / Mint)

  2. 酿造(用于MacOS)

  3. RPM (用于Fedora / Red Hat)

  1. apt-get (for Debian/Ubuntu/Mint)
  2. Brew (for MacOS)
  3. RPM (for Fedora/Red Hat)




注意:正如Martin Ullrich在评论中指出的那样,现在有一个使用NuGet部署构建工具CLI的方式,主要用于连续集成部署方案。

NOTE: As Martin Ullrich pointed out in the comments, there is now a way to deploy build tool CLIs with NuGet, which is primarily meant for continuous integration deployment scenarios.

这篇关于在NuGet中包含控制台应用程序的最佳实践的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆