誰かこのへん、わかりやすい画像作ってください...アプリケーションは、モジュールを利用します。利用するというような状況を考えます。両アプリケーションから利用されています。使っていたなんてことも、よくあります。動かなくなってしまっては困ります。昔はそういうことがありました。インストールしてくださいなんていう、今から見れば恐ろしいドキュメントがゴロゴロありました。解消を目的として、アセンブリという技術を導入しました。同じマシン上に共存でき、それぞれのアプリケーションから参照されます。登場によって、一層推し進められます。なくアプリケーションと同じディレクトリに配置され、他のアプリケーションからは参照されないからです。この方向性はさらに強化されます。ディレクトリを参照することもできます)。サーバーを立ち上げることができます(ファイアーウォールなんかの設定は必要だと思いますが)。これは特殊なシナリオです。ためにデザインされた仕組みです。アプリケーションは配置されません。アプリケーションが、少々多めにディスクスペースを占有しても構いません。それより優先すべきことがあるからです。一般のアプリケーションではそうはいきません。コピーを抱え込んだら、あっという間にディスクが枯渇してしまうでしょう。サイド性が求められる傾向にあるということは確かです。依存性はモジュール同士の間にある場合もあります。共存できるので問題はありません。インストールされているとしましょう。互換性が無いためインストールできない」というエラーになります。両立はできませんが、うっかり壊れてしまうということは避けられるわけです。モジュールには、元々、モジュール間に依存性を持たせる仕組みがあります。形式を採用したため、その機能を使っても、依存モジュールを定義することができます。あれば、依存関係にあるモジュールが芋蔓式にインストールされます。これが、プレビュー版ゆえの制限なのか、敢えての仕様なのかはわかりません。仕様でないとすれば問題があります。ディレクトリにモジュールをインストールします。サイド性がありません。発生する可能性があります。プレビュー段階のため、このような実験に都合のいいモジュールがありません。モジュールのアップロードができるようになったら、改めて実験してみるつもりです。アプリケーションについても考えてみましょう。書いたアプリケーションというものが考えられてもよいでしょう。今後発展してほしい分野です。モジュールを配布するために用意されています。モジュールは再利用されるための仕組みですが、アプリケーションはそうではありません。ディレクトリにインストールされるというのは、あまり嬉しい状況ではありません。ディレクトリ以外にモジュールを配置することも可能です。コマンドは、モジュール名だけでなく、パスを指定して読み込むこともできるからです。ディレクトリ下に配置して、アプリケーションと一緒にパッケージ化してしまうという手もあります。サイド性が成立します。配布すればよいと思います。アプリケーションもこれで配布しようというのは、やめた方がいいでしょうね。ダメなところ出番がないかと思っていたらまさかの呼び出し、そしてダメ出し。そのデザイン上仕方がないことではあるのですが、割とダメダメです。アプリケーションをパッケージ化して配布するための仕組みではないと言ってしまってもよいと思います。あれは、アプリケーションを簡単にインストールするための仕組みであって、それ以上でもそれ以下でもありません。パッケージがあります。インストーラーは入っていません。サイトからインストーラーをダウンロードして実行するためのスクリプトがあるだけです。パッケージの大半がこういう形態ではないかと思われます。なっていますが、こんなのは何とでも書くことができます。誰もチェックしていません。サイトからダウンロードしたインストーラーをパッケージに含めて配布したら、著作権的に問題になってしまいますよね。再配布契約を結んでいればいいんですけど...。いうのは基本的に、(パッケージ内にあるか、都度ダウンロードするかはともかくとして)インストーラーを取得して実行するための手段です。