これはとてもシンプルなものの1つで、私が読んだチュートリアルで誰も出てこないと言っています。Visual Studioの.NETプロジェクトは、常に1つのファイルにコンパイルされますか？
私はいくつかのスタンドアロンの.NETアプリケーションだけでなく、他のプログラム用のいくつかのDLLベースのプラグインを作成しています。 Visual Studioのプロジェクトは、少なくともWindowsのアプリケーションやクラスライブラリでは、単一のファイル（EXEまたはDLL）にコンパイルされていることに気付きました。
これはいつものケースですか？より大きなアプリケーションを編成するという観点からは、私はいつもVisual Studioのプロジェクトを最終的なプログラムの1つのファイルに対応するものと考えるべきでしょうか？
各プロジェクトには、単一のファイルにコンパイルありません。
ただし、プロジェクトの任意のファイルのビルドアクションを[常にコピー]または[新しい場合はコピー]に設定すると、プロジェクトはそのファイルを出力フォルダにコピーします。
また、EXEプロジェクトにApp.configファイルがある場合、出力フォルダにもコピーされます。
あなたのプロジェクトがコアフレームワークの一部ではないDLL（自分自身か他の誰か）を参照している場合は、そのDLLをプロジェクトの出力フォルダにコピーします。その結果、2つのファイルが生成されます
また、DLLとEXEに加えて、出力フォルダにデバッグシンボルを含む.pdbファイルも作成されます。このファイルはデバッガで使用されるため、ユーザーに配布しないでください。 （あなたのコードをデバッグしない限り）
はい、はい。インターネットで "netmodule"を検索すると、探しているドキュメントが見つかります。複数のプロジェクトを1つのDLLにまとめることを検討していた今日、私はそれらを見つけました。
MSDN：http://msdn.microsoft.com/en-us/library/226t7yxe(VS.80).aspx
必ずしもそうである必要はありません。プロジェクトにカルチャー指向のリソースがある場合、それらは通常、別々のアセンブリ（dll）にコンパイルされます。また、ASP.Netプロジェクトは1つのアセンブリにコンパイルされません。常に、aspx/ascxファイルまたはコンパイラのマーカーに相当するものがコンパイルされたコードとは別のものになります。
_Web Site Projects_は単一のアセンブリにコンパイルされません。コンパイルされません。 _Webアプリケーションプロジェクト_ _doは単一のアセンブリにコンパイルされます。 –
良い点 - 私がやるウェブのすべてのものは、Webアプリケーションプロジェクトなので、違いを言い表すのは忘れてしまいました:) – slugster
Web Deploymentプロジェクトを使用する場合でも、それらを1つのアセンブリにコンパイルできます。 Aspnet_merge.exeは魔法を実行します。 –
単純なプロジェクトでは、プロジェクトごとに1つのアセンブリが常に得られます。しかし、より多くのプロダクション対応ソフトウェアに移行すれば、その答えは異なります。たとえば、DLLを配信したいとしますが、ユーザーに表示する必要があるテキストが含まれているとします。そのテキストをローカライズしたいと思うかもしれません（英語とドイツ語のバージョン、または英語と英国の英語を提供する[プログラムとプログラムを考える]）。テキストをリソースに配置し、それらのリソースを衛星アセンブリと呼ばれるものにコンパイルします。サポートするロケールごとに1つのサテライトアセンブリを取得します。私は人々がnetmodulesとILMergeの話を参照http://sanjaysainitech.blogspot.com/2007/08/satellite-assemblies.html
：
はここでダウンサテライトアセンブリを生成し、使用方法の迅速な実行します。私はあなたがネットモジュールについて心配しているなら、あなたがMicrosoftから与えられたツールを使用していない（または、あなたがMicrosoftのツールを使用していないMonoで終わった）ので、間違ったことをしていると思います。私はILMergeを使用していませんが、それについて読んだ後、私はそれを信頼するかどうかはわかりません。 This personは、WPF/XAMLコードを除いて正常に動作すると言います。 this personは、ILMergeの実行後に組み込みリソースへのアクセスに問題がありました。 this person ILMergeを実行した後にデバッガを使用してもステップアップできなかった最適化されたコードを検出しました。これは、ILMergeがすべてのシナリオで実稼動可能なツールではないことを示す十分な情報です。ソフトウェアの設計の一環として、ソフトウェアをどのように展開するかが考えられます。より少数のアセンブリを展開したい場合は、コンパイルした後にILで心配するのではなく、ソフトウェアをそのように設計する必要があります。地図製作者たちは、「ここはドラゴンズ」と言っていました。単一のDLLにいくつかのモジュールとリンクのテーマを作成する方法
例：
csc /t:module RarelyUsedTypes.cs
csc /out:AllTypes.dll /t:library /addmodule:RarelyUsedTypes.netmodule AllTypes.cs
詳細についてはリヒターの本CLR via C#を参照してください。
Visual Studioのこのプロセスを自動化することができます。
プロジェクトごとに、ネットモジュールまたはアセンブリを作成し、それらをすべて1つのアセンブリにコンパイル/マージします。
第1の代替案。これはJay R. Wrenによって提案された：
これはかわいいハックですが、CSCとVBCとの両方
/target:moduleと/addmoduleオプションをサポートしている、あなたは実際にはシェルスクリプトを使用してILMergeせずにこれを行うことができますまたはファイルを作成します。Visual Studioは "netmodule"タイプをサポートしていませんが、MSBuildはサポートしています。
ソリューションにVBプロジェクトを追加します。プロジェクトをアンロードし、プロジェクトファイルを編集します。
変更OUTPUTTYPE、モジュールに：
<OutputType>module</OutputType>
代わりの目的のプロジェクトへの参照を追加することを、我々はモジュールを追加します。悲しいことに、ここでもVStudioは失敗しますが、MSBUILDはうまく動作します。プロジェクトをアンロードし、プロジェクトファイルを編集します。 AddModulesインクルードディレクティブを含むアイテムグループを追加します。
<ItemGroup><AddModules Include="..\VbXml\bin\Debug\VbXml.netmodule" /></ItemGroup>
これは単にメーカーが管理しない参照項目のグループのように、
/addmoduleディレクティブを使用するCSCを伝えるためのMSBuildを教えてくれます。
主な欠点：追加されたモジュールのVisual Studio Intellisenseはありません。私たちはすでにリファレンスを持っていますが、私たちはモジュールを持っていません。[更新：@ Ark-kunは、Visual Studioは.netmoduleプロジェクトを参照し、Intellisenseを参照できることを指摘しました。 ]SharpDevelopには最初のステップがありますが、2番目のステップである「Add Module」GUIはSD 2.0以降の優先度の低いアイテムとして公開されています。
第2の代替案。このgreat article（Scott Hanselman）は、Visual Studioを使用している場合、自動的にアセンブリをどのように巨大化するかについて説明しています。は、最初の代替品とは異なり、IntelliSenseサポート
を提供します。
3つの方法すべてが1つのアセンブリを生成します。しかし、3番目の方法だけがあなたに1つの**ファイル**を与えます。 –
「AddModulesインクルードディレクティブを持つアイテムグループを追加してください。 '.csproj'の'
@ Ark-kun：スキーマ違反は問題ではありません。私はあなたに何かが間違っているかもしれないというヒントだと考えています（違反がなければならない場合を除きます）。 –
ネットモジュールは反対です。私も彼らに騙されました。ネットモジュールを使用すると、アセンブリを複数のファイルに分割することができます（たとえば、それらを個別にロードすることができます）。それらは通常の参照されたdllに非常に似ています。あなたのリンクステートネットモジュールは "マルチファイルアセンブリ"を作成することを可能にします。 –