GUIプログラムとコンソールアプリケーションを単一のEXEに結合するのは悪い考えですか？

Question

私はWPFベースのインターフェイスを持つ小さなユーティリティを書いています。また、コマンドラインパラメータでプログラムを実行することで、ユーティリティが実行するタスクと同じタスクを自動化できるようにしたいと考えています。これらのタスクを両方とも1つのプログラムにまとめるのは悪い考えですか？私は、私のツールが別の共有ライブラリで実行する実際のロジックと機能を持っています。したがって、別々のものであれば、大量のコードを複製することはありません。

私は、私は別のホストのプロジェクトから呼び出される機能クラスライブラリを作成します。この場合、

private void Application_Startup(object sender, StartupEventArgs e) 
    { 
     if (e.Args.Length > 1) 
     { 
      //Go do automated tasks 
     } 
     else 
     { 
      //open GUI 

      Window window = new Window(); 

      this.MainWindow = window; 

      window.Show(); 
     } 
    } 

Answer 1

ファイル私App.csにこのような何かをやって考えていました。 MyApp.WPFは、MyLibをdllとして参照します... MyApp.Consoleは、MyLibをdllとして参照します。

編集した機能を持つクラスライブラリが既にあります。同じアプリケーションにそれを保持することの本当のメリットは何ですか？

Answer 2

コマンドラインから自動化されたタスクやオプションを設定するには、間違いなくこれを行うことができますが、WPFアプリケーションにはコンソールウィンドウがないので、Console.WriteLine()などを使用することはできません。コンソール出力が必要ない場合は、大したことではないかもしれません。

コンソールウィンドウをWPFアプリケーションに接続するためのいくつかのひどいwin32ハックがあるかもしれませんが、私はそれをお勧めしません。実際のコンソールが必要な場合は、ライブラリのWPFとコンソールフロントエンドの両方をビルドする方法があります。

Options.csでも、C＃でコマンドライン引数の処理を行うことをお勧めします。

編集：私はこのすべてについて間違っているかもしれない、コメントを見てください。 ALSO

：コンソールアプリケーション対Windowsアプリケーションについての関連情報：Difference between Windows and Console application

Answer 3

これは、コンソールモードアプリではありませんので、あなたが実際にコンソールを作成していません。

引数を受け入れるGUIプログラムは、全く正常です。ボイラープレートの例はfile associationです。エクスプローラで.slnファイルをダブルクリックすると、Visual Studioが起動し、ソリューションがロードされます。ビットマップをダブルクリックするとMS-Paintが起動します。 Etcetera。クリックされたファイルのパスは、コマンドインタープリタで入力したのと同じように、コマンドライン引数を介してプログラムに渡されます。

ウィンドウを作成するかどうかは、あなた次第です。問題を報告する必要性を忘れないでください。