是否可以将相同的 DLL 用于控制台应用程序和 NuGet 依赖项? [英] Is it possible to make the same DLL into both a console application and a NuGet dependency?
问题描述
我有一个面向 .NET Standard 1.5 的项目，该项目在 NuGet 上部署为多个 DLL.该项目是从 Java 移植过来的.在项目的一些类中是静态的 Main() 方法，旨在从命令行运行.
I have a project that targets .NET Standard 1.5 that is deployed as several DLLs on NuGet. The project was ported from Java. Inside some of the classes of the project are static Main() methods that are meant to be run from the command line.
在 .NET Core 中似乎有 2 种编译 DLL 的方法:
In .NET Core it seems there are 2 ways to compile a DLL:
<OutputType>Exe</OutputType>- 编译成一个可执行的控制台应用程序 (DLL)Library
<OutputType>Exe</OutputType>- compiles into an executable console app (DLL)<OutputType>Library</OutputType>(default) - compiles into a class library (DLL)
我想知道有没有一种方法可以编译 DLL，这样它就可以以任何方式使用而没有 2 个单独的(令人困惑的)DLL?
What I am wondering is there a way to compile the DLL so it can be used either way without having 2 separate (confusing) DLLs?
基本上，我试图获得类似于 Java 中的功能，其中包可以被应用程序引用或在命令行上运行(以及在命令行中指定入口目标).
Basically, I am trying to get similar functionality to that in Java where a package can be referenced by an application or run on the command line (and to specify the entry target on the command line).
例如，在 Java 中，有些文件既是包的一部分，又包含 静态 Main(object[] args) 方法.
For example, in Java there are files that are both part of the package and contain a static Main(object[] args) method.
public class SomeClass
{
public void DoSomething(string arg1, string arg2, string arg3)
{
// implementation...
}
public static void Main(object[] args)
{
// parse args...
new SomeClass().DoSomething(arg1, arg2, arg3);
}
}
DoSomething 在包内的其他地方被引用(这相当于我的 NuGet 包现在的样子).但是，在 Java 中，Main(object[] args) 可以从命令行运行，例如...
DoSomething is referenced elsewhere within the package (which is equivalent to what my NuGet packages look like now). However, in Java the Main(object[] args) can be run from the command line like...
java <package>.jar <namespace>.SomeClass [args]
无需下载或安装任何额外的东西.毕竟，如果用户想要在其上运行命令的组件在那里，那么所有依赖项也都在那里.
without having to download or install anything extra. After all, if the component the user wants to run the command on is there, all of the dependencies are there, too.
理想情况下，我可以只使用 dotnet 核心中的类似功能...
Ideally, I can just use similar functionality in dotnet core...
dotnet <assembly>.dll <namespace>.SomeClass [args]
这比必须围绕整个事物创建一个单独的包装器 DLL 或创建一个单独的项目更好，该项目必须选择 SomeClass 的所有依赖项，以便将它们全部编译成单个程序集(控制台应用程序).
which would be preferable to having to create a separate wrapper DLL around the whole thing, or make a separate project that has to pick and choose all of the dependencies of SomeClass so they are all compiled into a single assembly (console app).
此外，每个包有几个静态的 Main() 方法，这似乎在 .NET Core 早期已经得到支持，这就是我的 其他问题是关于.
Furthermore, there are several static Main() methods per package, which seems to have been supported in .NET Core earlier which is what my other question is about.
推荐答案
使用 .Net Standard/Core，您最好的选择是拥有第二个项目，该项目编译为具有简单 Main() 方法的 EXE，该方法指向图书馆的版本.这并不理想，但问题是 .Net 核心的运行时如何工作.以 .Net Standard 为目标的项目可以被与该标准版本兼容的所有项目使用.针对特定 .NetCoreApp 的项目只能被其他 .NetCoreApp 引用，因此您无法获得针对标准的好处.
With .Net Standard/Core, your best option is to have a second project that compiles to an EXE who has a simple Main() method that points to the library's version. It isn't ideal, but the issue is how the runtime for .Net core works. A project that targets .Net Standard can be used by all projects compatible with that standard version. A project that targets a specific .NetCoreApp can only be referenced by other .NetCoreApps, so you don't get the benefit of targeting the standard.
对于打包/NuGet 部署，控制台应用程序版本可以放在 NuGet 的工具文件夹中，以便最终用户可以使用它.您真的不希望通过标准 NuGet 内容文件夹部署可执行文件，因为它不会真正遵循标准并且会让您的 NuGet 用户感到困惑.
For the packaging/NuGet deployment, the console app version can be put into the tools folder of the NuGet so an end user can use it. You don't really want executables to be deployed via the standard NuGet content folder because it won't really follow the standard and be confusing for your NuGet users.
这篇关于是否可以将相同的 DLL 用于控制台应用程序和 NuGet 依赖项?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
