クラスライブラリのプロジェクトをdll化せずにexeに含めることは可能ですか？ への返答
投稿で使用できる特殊コードの説明。(別タブで開きます。)
以下の返答は逆順(新しい順)に並んでいます。
投稿者 ムサカ1998 (中学生)
投稿日時
2012/5/9 15:12:48
魔界の仮面弁士さま、書き込みありがとうございました。
色々と勉強になりました。
プロジェクト参照については、それ程大きなソリューションにはならないと思いますし、デバッグのしやすさもあるので、とりあえずは気にしなくてもいいかなと考えています。
みなさまの書き込み内容をよく勉強しようとおもいます。
ありがとうございました。
色々と勉強になりました。
プロジェクト参照については、それ程大きなソリューションにはならないと思いますし、デバッグのしやすさもあるので、とりあえずは気にしなくてもいいかなと考えています。
みなさまの書き込み内容をよく勉強しようとおもいます。
ありがとうございました。
投稿者 魔界の仮面弁士 (社会人)
投稿日時
2012/5/9 13:37:46
> 各アプリケーションのプロジェクトにコピーして使いまわしていましたが
コピーせず、1つの *.vb ファイルを複数のプロジェクトで共有することもできますよ。
既存の*.vb をプロジェクトに追加する際、ダイアログの追加ボタン横の▼から
「リンクとして追加」を選ぶという手法です。
> 他のアプリケーションの共通クラスを修正し忘れることがあり
それはソース管理／リリース管理上の問題であって)、
設計手法とは別の問題のようにも思えます。
> 名前空間の先頭がアプリケーションで変わってしまうため
C# とは違って、VB はプロジェクトごとに名前空間を設定できてしまいますからね…。
> プロジェクト参照することで対応可能と思いますが
プロジェクト参照を使った場合、ソリューションが大きくなるにつれ、ビルドしにくくなります。
(コンパイルに時間がかかる、ビルド時のメモリ消費量が跳ね上がるなど)
一方、DLL をバイナリ参照した場合は、EXE コンパイル時のリソース消費は減りますが、
DLL を更新した結果を反映させるための手間が生じるため、開発段階の初期では
使いにくい場合もありますね。
> どのようにクラスを管理すればよいか、わけが分からなくなってしまいました。
アセンブリ バージョンの参照に関する問題であれば、このあたり。
http://www.atmarkit.co.jp/fdotnet/technology/idnfw11_04/idnfw11_04_01.html
> ２．アプリケーション１はライブラリAを参照しています。
> ３．アプリケーション２はライブラリA・Bを参照しています。
> ４．ライブラリBはライブラリAを参照しています。
これはよくあるパターンですね。たとえば、.NET Framework 自体のライブラリでいえば
４．System.Windows.Forms.DLL は内部で Accessibility.DLL を参照しています。
３．WindowsApplication1.exe は前者を参照していますが、後者は参照していません。
２．WindowsApplication2.exe は前者も後者も参照しています。
のようなケースです。
上記のようなコードを書いた場合、AccessibilityObject プロパティの下に波線が
表示され、コンパイルエラーとなります。その波線部には、Accessibility.DLL を
参照設定するようにとの修正候補が記載されており、Accessibility.DLL を
追加で参照することで、エラーが解消されます。
> ライブラリの内容をアプリケーションのexeの中に含めたいのですが
DLL にしたうえで、それを埋め込む方法でも良ければ。
http://research.microsoft.com/en-us/people/mbarnett/ILMerge.aspx
http://www.atmarkit.co.jp/fdotnet/dotnettips/426ilmerge/ilmerge.html
コピーせず、1つの *.vb ファイルを複数のプロジェクトで共有することもできますよ。
既存の*.vb をプロジェクトに追加する際、ダイアログの追加ボタン横の▼から
「リンクとして追加」を選ぶという手法です。
> 他のアプリケーションの共通クラスを修正し忘れることがあり
それはソース管理／リリース管理上の問題であって)、
設計手法とは別の問題のようにも思えます。
> 名前空間の先頭がアプリケーションで変わってしまうため
C# とは違って、VB はプロジェクトごとに名前空間を設定できてしまいますからね…。
> プロジェクト参照することで対応可能と思いますが
プロジェクト参照を使った場合、ソリューションが大きくなるにつれ、ビルドしにくくなります。
(コンパイルに時間がかかる、ビルド時のメモリ消費量が跳ね上がるなど)
一方、DLL をバイナリ参照した場合は、EXE コンパイル時のリソース消費は減りますが、
DLL を更新した結果を反映させるための手間が生じるため、開発段階の初期では
使いにくい場合もありますね。
> どのようにクラスを管理すればよいか、わけが分からなくなってしまいました。
アセンブリ バージョンの参照に関する問題であれば、このあたり。
http://www.atmarkit.co.jp/fdotnet/technology/idnfw11_04/idnfw11_04_01.html
> ２．アプリケーション１はライブラリAを参照しています。
> ３．アプリケーション２はライブラリA・Bを参照しています。
> ４．ライブラリBはライブラリAを参照しています。
これはよくあるパターンですね。たとえば、.NET Framework 自体のライブラリでいえば
４．System.Windows.Forms.DLL は内部で Accessibility.DLL を参照しています。
３．WindowsApplication1.exe は前者を参照していますが、後者は参照していません。
２．WindowsApplication2.exe は前者も後者も参照しています。
のようなケースです。
Public Class Form1
Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load
Dim a As Object = Me.AccessibilityObject
End Sub
End Class上記のようなコードを書いた場合、AccessibilityObject プロパティの下に波線が
表示され、コンパイルエラーとなります。その波線部には、Accessibility.DLL を
参照設定するようにとの修正候補が記載されており、Accessibility.DLL を
追加で参照することで、エラーが解消されます。
> ライブラリの内容をアプリケーションのexeの中に含めたいのですが
DLL にしたうえで、それを埋め込む方法でも良ければ。
http://research.microsoft.com/en-us/people/mbarnett/ILMerge.aspx
http://www.atmarkit.co.jp/fdotnet/dotnettips/426ilmerge/ilmerge.html
投稿者 ムサカ1998 (中学生)
投稿日時
2012/5/9 13:24:52
るきおさま、書き込みありがとうございました。
dll化したくなかったのは、他のPCにexeをコピペして動かす程度のソフトなので、実行ファイルの他にファイルが増えることが嫌だなあ、というだけの理由です。
やはり、メンテヌンスのしやすさを考えて、dll化はやむなしと考え、クラスライブラリ（あるいはそれに関連するクラス）毎にプロジェクトを作成して運用しようと思いますが、各プロジェクト単位で編集を行うには、今回の例の場合に作成するソリューションは以下の通りでよいでしょうか？
・ライブラリA用プロジェクト
・ライブラリB用プロジェクト（ライブラリA用プロジェクトを参照）
・アプリケーション１用プロジェクト（ライブラリA用プロジェクトを参照）
・アプリケーション２用プロジェクト（ライブラリA用プロジェクト・ライブラリB用プロジェクトを参照）
ライブラリAとライブラリBを同じプロジェクトにしようとも考えましたが、アプリケーション1ではライブラリBを参照しないので、きっちり分けようと思いました。
dll化したくなかったのは、他のPCにexeをコピペして動かす程度のソフトなので、実行ファイルの他にファイルが増えることが嫌だなあ、というだけの理由です。
やはり、メンテヌンスのしやすさを考えて、dll化はやむなしと考え、クラスライブラリ（あるいはそれに関連するクラス）毎にプロジェクトを作成して運用しようと思いますが、各プロジェクト単位で編集を行うには、今回の例の場合に作成するソリューションは以下の通りでよいでしょうか？
・ライブラリA用プロジェクト
・ライブラリB用プロジェクト（ライブラリA用プロジェクトを参照）
・アプリケーション１用プロジェクト（ライブラリA用プロジェクトを参照）
・アプリケーション２用プロジェクト（ライブラリA用プロジェクト・ライブラリB用プロジェクトを参照）
ライブラリAとライブラリBを同じプロジェクトにしようとも考えましたが、アプリケーション1ではライブラリBを参照しないので、きっちり分けようと思いました。
投稿者 (削除されました) ()
投稿日時
2012/5/9 13:18:38
(削除されました)
投稿者 (削除されました) ()
投稿日時
2012/5/9 13:16:39
(削除されました)
投稿者 るきお (社会人)
投稿日時
2012/5/9 12:55:04
マルチファイルアセンブリを使えば望みのことは可能かも知れませんが、これは非常にまれな技術で、お手軽でもありません。
http://msdn.microsoft.com/ja-jp/library/226t7yxe(v=vs.80).aspx
その他の手段では思いつきません。
ただ、dllの方がお手軽で扱いややすいと思うのですが、なぜdllが嫌なのでしょうか？
その原因をつぶした方が良いと思います。
参考：dllを前提にした通常のクラスライブラリの開発についてはここで説明しています。
http://homepage1.nifty.com/rucio/main/dotnet/shokyu/standard51.htm
http://msdn.microsoft.com/ja-jp/library/226t7yxe(v=vs.80).aspx
その他の手段では思いつきません。
ただ、dllの方がお手軽で扱いややすいと思うのですが、なぜdllが嫌なのでしょうか？
その原因をつぶした方が良いと思います。
参考：dllを前提にした通常のクラスライブラリの開発についてはここで説明しています。
http://homepage1.nifty.com/rucio/main/dotnet/shokyu/standard51.htm
投稿者 ムサカ1998 (中学生)
投稿日時
2012/5/9 11:36:20
こんにちは。
趣味でVB（2008）を使って色々なツールソフトを作っていて、共通で使用しているクラスの.vbファイル単位で各アプリケーションのプロジェクトにコピーして使いまわしていましたが、あるアプリケーションのプロジェクト内で共通クラスを直したとき、他のアプリケーションの共通クラスを修正し忘れることがあり、また、名前空間の先頭がアプリケーションで変わってしまうため、クラスライブラリ化を行おうと思っています。
ただし、例えば、以下のような場合、どのようにクラスを管理すればよいか、わけが分からなくなってしまいました。
１．アプリケーション１・２があり、ライブラリA・Bがあるとします。
２．アプリケーション１はライブラリAを参照しています。
３．アプリケーション２はライブラリA・Bを参照しています。
４．ライブラリBはライブラリAを参照しています。
おそらく各ライブラリをプロジェクト化して、各アプリケーションまたはライブラリでプロジェクト参照することで対応可能と思いますが、出来ればライブラリをdll化せず、ライブラリの内容をアプリケーションのexeの中に含めたいのですが、そのようなことは可能でしょうか？
無理であればdll化も検討します。
分かりにくい文章ですみません。
趣味でVB（2008）を使って色々なツールソフトを作っていて、共通で使用しているクラスの.vbファイル単位で各アプリケーションのプロジェクトにコピーして使いまわしていましたが、あるアプリケーションのプロジェクト内で共通クラスを直したとき、他のアプリケーションの共通クラスを修正し忘れることがあり、また、名前空間の先頭がアプリケーションで変わってしまうため、クラスライブラリ化を行おうと思っています。
ただし、例えば、以下のような場合、どのようにクラスを管理すればよいか、わけが分からなくなってしまいました。
１．アプリケーション１・２があり、ライブラリA・Bがあるとします。
２．アプリケーション１はライブラリAを参照しています。
３．アプリケーション２はライブラリA・Bを参照しています。
４．ライブラリBはライブラリAを参照しています。
おそらく各ライブラリをプロジェクト化して、各アプリケーションまたはライブラリでプロジェクト参照することで対応可能と思いますが、出来ればライブラリをdll化せず、ライブラリの内容をアプリケーションのexeの中に含めたいのですが、そのようなことは可能でしょうか？
無理であればdll化も検討します。
分かりにくい文章ですみません。
http://www.atmarkit.co.jp/fdotnet/dotnettips/426ilmerge/ilmerge.html