DLLファイルを一般的に配置する場所

Question

前提・実現したいこと

DLLファイルは一般的にプロジェクトのどのディレクトリに配置すべきでしょうか？
何か新しいディレクトリ等を作成してその中に格納した方がよいのでしょうか(命名規則等ありますか)？
クラスライブラリとしてDLLファイルを使用することを考えています。
検索しても情報が見つからなかった為、ご教示をお願いします。

試したこと

C#でプロジェクトを作成するところまではできました。

│  Program.cs
│  TestApp.csproj
│
├─.vscode
│      launch.json
│      tasks.json
│
├─bin
│  └─Debug
│      └─netcoreapp2.1
│              TestApp.deps.json
│              TestApp.dll
│              TestApp.pdb
│              TestApp.runtimeconfig.dev.json
│              TestApp.runtimeconfig.json
│
└─obj
    │  project.assets.json
    │  TestApp.csproj.nuget.cache
    │  TestApp.csproj.nuget.g.props
    │  TestApp.csproj.nuget.g.targets
    │
    └─Debug
        └─netcoreapp2.1
                TestApp.AssemblyInfo.cs
                TestApp.AssemblyInfoInputs.cache
                TestApp.assets.cache
                TestApp.csproj.CoreCompileInputs.cache
                TestApp.csproj.FileListAbsolute.txt
                TestApp.csprojAssemblyReference.cache
                TestApp.dll
                TestApp.pdb

デフォルトのdllファイルは下記2つの場所にあることがわかりました。
どちらもDebugフォルダの中にあるのが微妙な気もします。

\bin\Debug\netcoreapp2.1\TestApp.dll
\obj\Debug\netcoreapp2.1\TestApp.dll

補足情報（FW/ツールのバージョンなど）

Windows 10

Comments

[退会済みユーザー]

何を作っているか (Windows Forms? WPF? ASP.NET? その他？) と開発環境 (Visual Studio などのバージョン、CORE のようですがそれならその旨明記してそのバージョン) を書きましょう。

[退会済みユーザー]

ご指摘ありがとうございます。
dotnet new consoleで作成するアプリケーションです。

[退会済みユーザー]

それは何なのですか？　自分がどういう環境で何を作っているか理解されてますか？　今回の質問は .NET Core の FDD 展開とか言うやつではないのですか？

掲題の DLL という言葉からは、.NET Framework ベースのクラスライブラリの .dll を想像する人が多いと思います。なので、そのあたりをきちんと書かないと、話が噛み合わなくなりますよ。

Answer 1

Visual Studio Code ではなく、Visual Studio をお勧めします。初心者なら猶更です。

それはそれとしてコマンドラインで茨の道(というほどでもありませんが)を歩む場合の話です。その前に、ソリューションというものがあり、これは複数のプロジェクトをたばねたものであることを前もって言っておきます。

ここでソリューションの名前を仮に Study ライブラリプロジェクトの名前を Lib アプリケーションプロジェクトの名前を App とします。今時の Test と言うのは、コードをデバッグするための仕組みを主に指しますので、あまりそれ以外で使わない方がいいのではないかと思います。

この時次のようにするのが一般的ではないかと思います。「#」以降はコメントですから打ち込まないでください。

mkdir Study # ソリューションフォルダの作成
cd Study
dotnet new sln # ソリューションの作成
mkdir Lib # ライブラリプロジェクトフォルダの作成
cd Lib
dotnet new classlib # ライブラリプロジェクトの作成
dotnet sln ..\Study.sln add .\lib.csproj # ライブライプロジェクトをソリューションに追加
cd ..
mkdir App # アプリケーションプロジェクトフォルダの作成
cd App
dotnet new console # コンソールアプリプロジェクトの作成
dotnet sln ..\Study.sln add .\App.csproj # アプリプロジェクトをソリューションに追加
dotnet add reference ..\Lib\Lib.csproj # ライブラリプロジェクトの参照をアプリプロジェクトに追加
cd .. # ソリューションフォルダに移動
dotnet build # ソリューションのビルド
dotnet run -p App # アプリ開始

出力フォルダの名前が Debug になっているのは、それがデバッグビルドだからです。リリースビルドを行うにはソリューションフォルダで dotnet build -c Release を実行してください。
同様にリリースビルドでアプリを実行するには dotnet run -p App -c Release としてください。

Comments

[退会済みユーザー]

ご回答ありがとうございます。
今までVisual Studioを使っていたのですが、重たくてVSCode+C#の開発手法に手を出したのですが、茨の道かもしれないのであれば、簡単な文法確認の用途ぐらいでVSCode+C#を試す程度に留めたほうがよいのかなと思い始めました。
なるほど、プロジェクトで1アプリケーションの単位になるかと思っていたのですが、複数のプロジェクトを束ねるソリューションというものがあるのですね。
ご教示いただいた方法はクラスライブラリのプロジェクトごとソリューションの中に含める方法みたいですが、コンパイル済みの単体のクラスライブラリdllファイルを取り込む方法ってあまりしない(というより、できない)ものですか？
例えば、
using System;

namespace testlib
{
public class Class1
{
public static void methodA(){
Console.WriteLine("DLL Method");
}
}
}
でコンパイルしたdllを、コンソールプロジェクトフォルダ直下のlibフォルダの中に格納して、
下記のように参照して使おうと思ったのですが、できなかったので、
こういった使い方はできないものですか？
namespace TestApp
{
class Program
{
static void Main(string[] args)
{

Console.WriteLine("Hello World!");
methodA();
}

[DllImport("./lib/testlib.Dll", EntryPoint="methodA")]
public static extern void methodA();
}
}

[Zuishin]

プロジェクトフォルダの下には入れず同列に扱ってソリューションでまとめたほうがいいと思いますが、できなくはありません。
肝はここです。
> dotnet add reference ..\Lib\Lib.csproj # ライブラリプロジェクトの参照をアプリプロジェクトに追加

アプリケーションプロジェクトフォルダに移動してライブラリプロジェクトの .csproj を dotnet add reference してください。

[Zuishin]

ただ、守破離という言葉をご存じですか？
https://henmo.net/2016/04/22/okazaki-taiiku-pattern/

[退会済みユーザー]

ご回答ありがとうございます。
dotnet add reference .\lib\testlib.dll
を試してみた所、dotnet addはプロジェクトを参照するものということでエラーになりました。
守破離という言葉は存じ上げてなかったですが、お作法に従った方がよいということですね。
しかし、だいぶ私が勘違いしているのかもしれませんが、
ソリューション(もしくはプロジェクト)に、外部から単体のDLLファイルのみを持ってきて、読み込ませて使うという手軽なことはシステム的にできないことですか？(プロジェクトを作らずに)
例えば、外部から単体のクラスのcsファイル持ってきて、それをプロジェクトのどこかのディレクトリに置くだけで、そのクラスが扱えるのと同じように、DLLファイルはただそれがコンパイル済みなだけで、やっぱりどこかのディレクトリに単体で配置すれば使えるものかと思っていたのですが、勘違いでしょうか？

[Zuishin]

dll ではなく csproj です。プロジェクトがあるんだからプロジェクトを参照したほうが色々楽です。わざわざ難しくすることはないと思います。

[退会済みユーザー]

ご回答ありがとうございます。
プロジェクトで管理すべきなのですね。
勉強になりました。
ありがとうございました。

Answer 2

普通はexeと同じディレクトリです。
クラスライブラリが必要になったとき、どのように検索されるかはこちらに記載されていますので、それに則る必要があります。
ローカルディレクトリ以外にインストールする方法もありますが、複数のexeが関連する大規模なプロジェクトでなければそこまでしないでいいと思います。
拡張機能などで不特定のアセンブリを動的に読み込む場合は、ローカルディレクトリの下のlibraryとかから自前で探したりします。

アプリを配布する場合は、インストーラプロジェクトに任せるか、リリースビルドのディレクトリから必要なものだけを自前のスクリプトなどで抜き出してzip等にまとめて配布します。

クラスライブラリ(DLL)の名前付けはガイドラインがこちらにあります。
あくまでガイドラインなので守る必要はありませんが、別のプロジェクトにライブラリを流用する場合とかに名前の衝突など起こりうる問題を回避できるかもしれません。

Comments

[退会済みユーザー]

ご回答ありがとうございます。
DLLはexeからも読み込めたりするのですね。理解できてなかったです。
コンパイル前にクラスライブラリとして読み込みたい意図です。質問が明確でありませんでした。
ローカルディレクトリの下のlibraryフォルダというのは、プロジェクトフォルダ直下(.vscodeやbinやobjと同階層)にlibraryフォルダを作成するということでしょうか？

[toki_td]

あぁ、.NET Coreだから実行ファイルも(3.0でなければ)DLLですね、、、

> コンパイル前にクラスライブラリとして読み込みたい意図です。

もしかして既存のライブラリをプロジェクトから参照する場合に、そのライブラリ自体をどう管理するか、の話をされてます？
これは個人やチームによると思いますが、プロジェクトよりも1階層上にまとめておくのが一般的じゃないでしょうか？

TestApp
　　+-- TestApp
　　| 　　+--- *.csprj, *.cs等
　　|
　　+-- library
　　　　+--- ～.dll

別の場所に置いておくと関係のない別のプロジェクトで同じライブラリの別バージョンが必要になった場合に競合してしまいますし、一緒に管理したほうがいいと思います。

> ローカルディレクトリの下のlibraryフォルダというのは、～

これはアプリにプラグイン機能等を作る場合の話なので気にしないでください。

[退会済みユーザー]

ご回答ありがとうございます。
>もしかして既存のライブラリをプロジェクトから参照する場合に、そのライブラリ自体をどう管理するか、の話をされてます？
はい、そうです。
プロジェクトよりも1階層上になりますか。

dotnet new consoleでプロジェクトを作成しているのですが、
これで作成すると、プロジェクト名フォルダ直下に、質問で提示したツリー構造のフォルダ、ファイル類が作成されるので、元の状態は、プロジェクト名フォルダの1階層上には、プロジェクト名のフォルダが存在しないのですが、作った方がよいということですか？
プロジェクト名フォルダ直下に(プロジェクト(TestApp.csproj)と同階層)に、libraryフォルダを作成して、その中にライブラリdllを格納するのはあまりよくないですか？

[toki_td]

1つのプロジェクトは1つのアセンブリを作成するためのものですから、既存のアセンブリは自作のプロジェクトと同列にあるのが正しいと思います。ですので、プロジェクトよりも1つ上の階層をお勧めします。
そうしないと、自前のクラスライブラリのプロジェクトをもう1つ追加したとして、複数のプロジェクトが既存のライブラリに依存する場合、複数の場所にコピーしたり別のプロジェクトのディレクトリを参照する変な構造になってしまいます。

あと、Zuishinさんも言われている通り、僕も最初の勉強にはVisual Studioをお勧めします。
確かにVS Codeのほうが軽いですが、VSだと勝手にやってくれるような、後々知っていけばいいことも最初に求められるので、入門にはちょっとハードルが高いのではと思います。

[退会済みユーザー]

ご回答ありがとうございます。
ソリューションや複数のプロジェクトを扱うときの構造などが理解できてませんでした。
勉強になりました。
ありがとうございました。

Answer 3

質問は .NET Core のコンソールアプリの FDD 展開というケースの話ではないですか？

.NET Core アプリケーションの展開
https://docs.microsoft.com/ja-jp/dotnet/core/deploying/

そうであれば、以下の記事が参考になりませんか？

.NET Coreでコンソールアプリを配置する
https://www.buildinsider.net/language/dotnetcore/04

Comments

[Zuishin]

vscode でプロジェクトのソリューションへの参加と参照の仕方がわからないという質問だと思いました。
という話かどうかを確認するのも難しそうなので回答してませんが。

[退会済みユーザー]

レスありがとうございます。vscode というのは触ったこともなく全く知らないのですが、どうも質問者さんと自分の話が噛み合ってなくて迷走してしまったような気がします。

[Zuishin]

いえ、私の考えも当てずっぽうなので。

[退会済みユーザー]

言葉足らずと説明不足ですみません。
昨日、初めてVSCodeでC#プロジェクト(dotnet new console)を作成し、
ビルドするとdllができあがることを知りました。
そこで、例えば、自作のCalcメソッドなどをdotnet new classlibで作成し、このCalcメソッドのライブラリdllを、dotnet new consoleで作成したプロジェクトにセットして呼び出したい場合、consoleプロジェクトのどこに配置したほうがよいのかという質問でした。
Zuishin様が推測されている質問になるかと思います。