実行用プロジェクトを作成

kzrnm commented 4 years ago

expander #30 のために実装したファイルですが、実行用プロジェクトはあったほうが良いかなと思います。

key-moon commented 4 years ago

私は無い方が簡潔かと思っていたのですが、元のライブラリが PC 初心者でも簡単に使えるように配慮されていた関係でしょうか…？元の ACL でも導入方法はマニュアルに書くに留めているので、なくてもよいと思います。

kzrnm commented 4 years ago

どのような導入方法を想定されていますでしょうか。

実行用プロジェクトを含めないならば、以下のような実装になるかと思います。internalのことを考えると、上2つが現実的でしょうか。

C# は基本的に単一ファイルでの実行を想定していないので、 C++ と同じように扱うのは特にメリットではないと感じます。

`AtCoderLibrary` をローカルの実行用プロジェクトに追加する

メリット

git clone したらそのまま追加できる。
- ただし、AtCoderLibrary.sln があるディレクトリが挟まってすこし余計。
- AtCoderLibrary.sln と AtCoderLibrary.csproj が同じディレクトリにある構成に変更すれば1階層で済む。

デメリット

expander 必須
プロジェクトの追加手順が必要

実行用プロジェクトを用意する

メリット

git clone したらそのまま実行できる。

デメリット

expander 必須

`AtCoderLibrary` 以下のファイルを実行ファイルと同じパスにコピーする

メリット

C++版と同じ仕様。

デメリット

expander 必須。
git clone したあとに、さらにファイルのコピーが必要。
同じアセンブリなので internal が無意味になってしまう。
実行用の .csproj と AtCoderLibrary.csproj が紛らわしい。

使う箇所をコピペする

メリット

git clone すら必要ない。
expander 不要

デメリット

依存関係も把握していなければならないので現実的ではない。
同じアセンブリなので internal が無意味になってしまう。

key-moon commented 4 years ago

プロジェクトに対する追加方法としては、ローカルの実行用プロジェクトに外部DLLとして AtCoderLibrary の参照を追加した時の挙動と同様の挙動になるような追加方法を想定しています。つまり、将来的に外部ライブラリとして他のオンラインジャッジに追加する際、NuGet 等でライブラリとして読み込めるような形にしたいです。ユーザーには主にソリューションにプロジェクトを追加した上で、プロジェクトへの参照を追加してもらう（つまり、今作成した実行用プロジェクトと同様のものを作成してもらう）ことになります。

ただ、そのユーザーが作成する空の実行用プロジェクトがあるのはそれはもはやライブラリではなく、競プロ用のプロジェクトの整備なのでは?と私は感じます。（これは個人の印象なので、他の人の意見も聞きたいです。）それを作成することを支援するためのスクリプトを含める程度が現実的な落とし所だと私は考えました。

単一ファイルでの実行を想定していないので、 C++ と同じように扱うのは特にメリットではないと感じます。

C++ と同様の導入マニュアル作成については、単一ファイルかそうでないかはあまり関係ないと思いますがいかがでしょうか。ACL を導入した C++ は複数ファイルでの実行になりますし、Expand しての提出の方法を考慮に入れた C++ の導入マニュアルは大いに参考にするに値するはずです。

terry-u16 commented 4 years ago

私も最終的な形としては（すぐにできるかどうかは置いておいて）NuGetで導入可能なdll形式での配布をイメージしていました。各自整備されている競プロライブラリにはいろいろな形があると思います（例えば.csprojファイルのchecked/unchecked設定、null許容設定等？）ので、ACLがマスター側になってこちらに合わせてもらうというよりは、各自の競プロライブラリにアドオン的に付け足す形が良いのかな、と思っています。

kzrnm commented 4 years ago

各自の競プロライブラリにアドオン的に付け足す

そうですね。腑に落ちる表現です。一旦閉じたいと思います。

kzrnm / ac-library-csharp