2017-06-29 6 views
2

NuGetに複数のDLLとして配備された.NET Standard 1.5を対象とするプロジェクトがあります。このプロジェクトはJavaから移植されました。プロジェクトのいくつかのクラスの中には、コマンドラインから実行される静的なMain()メソッドがあります。 .NETのコアで同じDLLをコンソールアプリケーションとNuGetの両方の依存関係にすることはできますか?

2 ways to compile a DLLがあるようだ。

  • <OutputType>Exe</OutputType> - 実行可能なコンソールアプリケーション(DLL)
  • <OutputType>Library</OutputType>(デフォルト)にコンパイル - クラスライブラリ(DLL)
にコンパイル

DLLをコンパイルして使用できるようにするにはどうすればいいですかいずれかの方法 2つの別々の(紛らわしい)DLLがなくてもかまいませんか?

基本的には、コマンドライン(specify the entry target on the command line)で実行されるアプリケーションまたはによってパッケージが参照されるJavaでの機能と同様の機能を実現しようとしています。

例えば、Java(登録商標)の両方パッケージ静的Main(object[] args)メソッドを含むの一部であるファイルが存在します。

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)は余分な何かをダウンロードまたはインストールすることなく、のような...

java <package>.jar <namespace>.SomeClass [args] 

コマンドラインから実行することができます。結局のところ、ユーザーがコマンドを実行したいコンポーネントがあれば、すべての依存関係もそこにあります。

理想的には、私はちょうどsimilar functionality in dotnet core ...

全部の周りに別のラッパーDLLを作成することに好ましいこと、またはすべてを選択し、選択しなければならない別のプロジェクトになるだろう
dotnet <assembly>.dll <namespace>.SomeClass [args] 

を使用することができますSomeClassの依存関係のため、それらはすべて1つのアセンブリ(コンソールアプリケーション)にコンパイルされます。

さらに、パッケージあたりいくつかの静的メソッドがあります。これは.NET Coreで以前サポートされているようですが、これはother questionです。

+1

ロジックをNuGetパッケージにカプセル化し、それをコンソールアプリケーションから消費するのはなぜですか? – mason

+0

ユーザーにとって痛みのようです。プラットフォームごとに1つのバイナリパッケージを用意するほうが、フォルダにドロップしてCLIコマンドを実行するほうが、依存関係が完全に混乱するよりはるかに好ましいでしょう。私はその問題を解決するために(ILMerge for .NET Coreに似た)[ILLink](https://github.com/mono/linker)を調べています。 – NightOwl888

+1

実行可能アプリケーションをNuGet経由で配布していますか?これはNuGetの目的ではありません。 – mason

答えて

3

.Net Standard/Coreでは、ライブラリのバージョンを指す単純なMain()メソッドを持つEXEにコンパイルする2番目のプロジェクトを用意することをお勧めします。理想的ではありませんが、.Netコアのランタイムがどのように動作するかが問題です。ターゲットとするプロジェクト。Net標準は、その標準バージョンと互換性のあるすべてのプロジェクトで使用できます。特定の.NetCoreAppをターゲットとするプロジェクトは、他の.NetCoreAppsによってのみ参照されるため、その標準をターゲットとする利点はありません。

パッケージ化/ NuGetデプロイメントの場合、NuGetのツールフォルダにコンソールアプリケーションのバージョンを入れて、エンドユーザーが使用できるようにすることができます。実行可能ファイルは標準のNuGetコンテンツフォルダ経由で展開することを実際には望んでいません。なぜなら、実際には標準に準拠しておらず、NuGetユーザーにとって混乱するからです。

+0

.NET Standard/.NET Coreに関する問題を提起してくれてありがとう。私はそれが[ILLink](https://github.com/mono/linker)を使ってマージする能力に影響するかどうか疑問に思います。 – NightOwl888

+0

しかし、自己完結型のデプロイメントを実現するために[トレードオフ](https://docs.microsoft.com/en-us/dotnet/core/deploying/index)を利用したいのでなければ、それはEXEファイルではありませんあなたが言ったように。しかし、それは、余分なコンソールアプリをダウンロードせずに「うまく動作する」多目的DLLを作成する方法を見つけられないと、最終的には行く方法になるかもしれません。 – NightOwl888

+0

このスレッドを参照してください:https:// github。com/dotnet/corefx/issues/11672 - あなたの問題の1つは、各プラットフォームでそれを行う必要があると思います。自己完結型のデプロイメントへのあなたのリンクはおそらく最善の策だと思います。 –

0

.NET EXE(これはDLLと同じようにアセンブリであり、そのように参照することができます)で無料で入手できます。

DLLに近づくには、.Net DLLをコマンドラインから何らかの方法で使用できるようにする必要があります。いくつかのネイティブ互換エントリポイントを公開し、rundll32を使用してコマンドラインからアクセスすることは、それを達成するためのオプションです - Need to run a c# dll from the command line

+0

これは.NET Frameworkにのみ適用されるようです。私は.NET Coreをターゲットにして、クロスプラットフォームサポートを無料で入手できるようにしたいと考えています。 – NightOwl888

関連する問題