- - PR -
ユーザーコントロールのバージョンアップについて
投稿者 | 投稿内容 | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2007-09-10 16:45
こんにちは。いつもお世話になっております。
どうしても分からないので、質問させていただきます。 開発環境WindowsXP,VB.NET,Firebird TextBox,ComboBoxを継承したユーザーコントロールを作成しました。 他にもいろいろ作成してまとめたものを一本のDLLにしています。 新規にフォームを作成し、ツールボックスの表示で、上記DLLを指定して、 作成したコントロール(最新バージョン)をドロップして、動作も上手く いっています。 ところで、このユーザーコントロールで、ロード時のBackColorを赤にしたり、 変更を加えた上で、「厳密な署名」をつけ、バージョンをあげて、 リビルドして、保存しました。 この状態で、フォーム側の変更なしで、既に作成してある コントロール類はバージョンが最新にならないのでしょうか? ユーザーコントロール.DLLを変更しただけで、Form1.Exeを実行すれば 既に作成されたコントロールの背景色が赤には・・ 当然ですが、ソリューションを開いて、ツールボックスから 最新バージョンコントロールをドロップすればできますが、 最初に作成したものが更新される ということは不可能なのでしょうか? プライベート配置、GAC配置 いろいろやってみましたが、 そもそもできないのでしょうか?・・ DLL Hell 問題でバージョンが違うものが存在できて、ランタイムが検索する順番とかも 読みましたが、リビルドなしで、DLLの更新のみで、最新の状態にできないかな と 思いまして。最新のバージョンを検索して、見つかったら上書きして欲しい・・ 100近い画面をこれから数名の開発者で開発するにあたり、 作成したユーザーコントロールを配布しますが、このユーザーコントロールは カスタマイズ・またバグが発生するたびに修正・検証・・、その都度 画面を開いてビルドするのは問題で、もう.NET自体が使えないんじゃ・・という 雰囲気になっています。 ユーザーコントロールのバージョンアップについて、リビルドなしでの 更新について等、詳しい資料もしくはURLがあればどなたかご教授ください。 よろしくお願いいたします。 | ||||||||||||||||
|
投稿日時: 2007-09-10 17:29
こんにちは。
Windowsアプリケーションなんですかね? 私もお手伝いの開発で同じようなことをしていますが、 (私は主にカスタム(継承)コントロール、ユーザーコントロールのDLL作成を担当) 別に普通につかえてますけども。 単にソリューション・プロジェクトの構成がまずいんじゃないでしょうか? 私の場合、 1つのソリューションにカスタムコントロールDLLのプロジェクトや その他、画面類などのEXE・DLLのプロジェクトを全部ぶら下げています。 そしてカスタムコントロールDLLを参照設定する場合には、 「参照の追加」ダイアログでDLLを指定するのではなく、プロジェクトとして追加。 カスタムコントロールDLLの修正をしても これだけで勝手に最新のビルドができますけれども? 一つ一つプロジェクトをビルドしなくても、ソリューションのビルド一発です。 リビルドなしだと、DLL HELLになりそうですね。 カスタムコントロールだと実行時に明示的にロードするわけにもいかなさそうですし。 | ||||||||||||||||
|
投稿日時: 2007-09-10 18:11
そりゃあ、その .dll を使う側が「開発時・実行時に、どのようにその .dll を参照しているのか」によって異なります。
不可能なことはありません。
個人的には勝手に .dll なんか上書きされたらたまらんですね。そっちの方が普通の感覚だと思いますが。
最も単純な方法は、更新された .dll を各 .exe のお隣にコピーすることです。 VS のソリューションに .dll と .exe のプロジェクトがすべて登録されていて、.exe のプロジェクトで .dll のプロジェクトを「プロジェクト参照」している場合、.exe のビルドを行うと VS が勝手に最新の .dll をコピーしてくれます。 .exe のリビルドを行うことなく更新された .dll を使いたいのなら、.dll のコピーを VS に頼らずに実行すればよいだけの話です。 .dll のプロジェクトを「プロジェクト参照」しないで、「納得のいく状態の .dll」をソリューションディレクトリ配下の適当なトコに配置して、各 .exe のプロジェクトではそれを参照設定するようにするとよいかもしれません。 | ||||||||||||||||
|
投稿日時: 2007-09-11 09:51
ひどり様、Tdnr_Sym様、ご返信ありがとうございます。
実行時にどうやって参照しているのでしょうか?ランタイムの検索ですよね。 実は、ご指摘の
というのは何度もやって、Exeを実行しても、最新のdllを参照するわけでなく、 前のバージョンで作成されたコントロールの表示になっているのです。 同じフォルダ内部にExeと最新Dllを配置して、Exeを実行しても 例えばデフォルトカラーを変えたコントロールに更新されてはいないです。 ということは、一旦ユーザーコントロールをフォームに実装した後で、 ユーザーコントロールの外観(もしくは内容)の変更があった場合に、 バージョンをあげても、前回の機能が生きたままならば、 全てのコントロールを貼り付け直す という手間が生じませんか?? これでは、開発が本格的に始まってしまってからの、ユーザーコントロールの 修正を行っても、「また実装するの・・?」という他の開発者の不満が聞こえそうw
リンクとしての追加 のことでしょうか・・?
これは、ユーザーコントロールを作成している段階でテストフォームプロジェクトを追加 したりやっていたのですが、これを数名規模の開発者の各端末に組み込む・・となると ユーザーコントロールのプロジェクトを、他の開発者が触れる(修正可能な状態) ということでしょうか?ユーザーコントロールを触るのは担当二人だけで、画面開発者には 触って欲しくない。。ということはムリなのでしょうか? また、ソリューションのビルド一発なのはいいのですが、画面数が100もあり、 1つでもユーザーコントロールの修正があった場合に、 全画面を1つのソリューションでリビルドすると、どのくらいの時間が かかるのでしょうか・・(100もできるのでしょうか) ソリューション・プロジェクト・画面構成をこれから考えないといけませんが。 従来、VB6ではユーザーコントロールはOCXとしてレジストリに登録しており、 DLLもEXEも1つとしてリンクされ、1プロジェクトに1画面という概念で 現システムがあるのですが、これを.Net仕様にするには 構成からの新規開発しなければいけないのでしょうか? 長くなってしまいましたが、どなたかご助言いただけると 助かります。 よろしくお願いいたします。 | ||||||||||||||||
|
投稿日時: 2007-09-11 10:09
Load時にBackColorを赤に・・・とありますが、 そのユーザーコントロールのコンストラクタでプロパティの初期値に赤を指定したということでしょうか。それとも、イベントを使って初回表示時に赤を設定するようなコードを書いたということでしょうか。 コントロールのデザイン関連のプロパティは、 フォームデザイナによって InitializeCompornent 内に記述されていることも多いです。 この中に今までの背景色を設定するようなコードが書かれている場合、次のように色が設定されていき、結果的には今までの色のままになります。 1.ユーザーコントロールのコンストラクタで赤に設定 2.フォームの InitializeCompornent で今までの色に設定 フォームデザインのプロパティウィンドウで、 そのコントロールの BackColor プロパティが太字で表示されていたりしませんか? | ||||||||||||||||
|
投稿日時: 2007-09-11 12:27
masa さんが指摘されているように、「見かけが前バージョンと同じ」なだけで、実は「使用されているのは新バージョン」のコントロールだったりはしませんか?
旧バージョンの .dll がどこにも存在しない状況でも試してみましたか? ありもしない .dll を参照することは不可能ですよね。 [ メッセージ編集済み 編集者: 渋木宏明(ひどり) 編集日時 2007-09-11 13:45 ] | ||||||||||||||||
|
投稿日時: 2007-09-11 16:03
masa様、ひどり様 ご返信ありがとうございます。
Load時にBackColorを赤に・・というのは、フォームに実装しただけで、 コントロールの色が変更されていないといけないのに、変更されなかったのです。 場所は、UserControl内部のUserControl_InitProperties()で行っています。
ですが、色の設定を変更しても、FormのDesigner.VBソースを見て分かりましたが、 ドロップした段階で、色が決定されてしまっていました。 Designer.VBは全く触っていないのですが、フォームに貼り付けた段階で 勝手にコード生成するものですよね? ここが、変更前の色(ドロップした時の色)になっており、 結局はフォーム(画面)側の変更を行わないと 反映されないのか・・と思いました。が、 ユーザーコントロールのイベントでEnter時に特定のTextを設定したり、 PublicメソッドでMessageBoxを出力したり変更してみました。 それを、プロジェクトのビルド先をBin\Release以外の場所に指定し、 また、コントロールのビルド先も上記と同じ場所に指定して(上書き) コントロール側だけ修正してリビルドすると、反映されました(^^) また、「構成マネージャ」というので、Debugフォルダを削除したり しましたが、これが良かったのでしょうか? ちなみに参照のユーザーコントロールのプロパティ「特定バージョン」を「True」にすると、 コンパイルエラーとか出ましたが・・ 「False」だと上手くいきます。 今の結論からいくと、バージョンあげても関係なく、特定のフォルダにDLLを上書きすれば 同じフォルダ上のExeもそれを参照しています。 が、ユーザーコントロールの「プロパティ」が追加・削除など変更があった場合には フォームもコントロールを実装し直し ということでしょうか。 DLLが更新されれば、イベントや動きだけでなく、Designer.VBのソースも更新されるのは またムリな話なのでしょうか。 何度もすみません。 新規プロジェクト準備段階で、困惑しています。 よろしくお願いいたします。 | ||||||||||||||||
|
投稿日時: 2007-09-11 18:06
バージョン(AssemblyVersion)が変わると別アセンブリとして見られ、 厳密署名を行っている場合にはDLLロード時に例外が発生します。 各アプリケーションの参照設定変更・リビルドを行うか、 設定ファイルを使ってバージョンリダイレクトを行う必要があると思います。 また、コントロールのデザインプロパティに限ってですが、 System.ComponentModel.DesignerSerializationVisibility 属性を使うと、 そのプロパティの値をソースに書き込ませないようにすることができます。 (=プロパティウィンドウで設定しても保存されません。) ただ、既存のプロパティに対してこの属性を設定するには overload または new による上書きが必要になります。 既にリリースしてしまっているコントロールに対して記述されてしまったコードをクリアすることは難しいので、別途初期化メソッドを定義してLoad時などに強制的に設定するような対応が必要ではないでしょうか。強制的に値を変更することは決してよいことではありませんが。。。 |