C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[8]: クラスライブラリで利用する設定の利用手法

(過去ログ 20 を表示中)

[トピック内 11 記事 (1 - 11 表示)]　 << 0 >>

■8525 / inTopicNo.1)

　クラスライブラリで利用する設定の利用手法

▼■

□投稿者/ ふぇい (1回)-(2007/10/02(Tue) 12:06:12)

分類:[VB.NET/VB2005]　

ふぇいと言います。

掲示板やわんくまメンバーさんのブログ等を拝見させて頂いて参考にさせて頂いています。

現在、単一のEXEから複数のDLLを利用し(プラグインのようなイメージです)、
ある処理をさせるプログラムを作成しています。

この複数あるDLLに各々別の設定ファイルを持たせDLL処理内部で
利用させたく、単に各DLLプロジェクトのアプリケーション構成ファイル
で設定を持たせDLLに利用させようと思っていました。
しかしその後作成を進める中でDLLを呼び出すEXE側に
アプリケーション構成ファイルを持たせないとDLL側で設定情報が参照できず、
結果、EXE側に膨大な量の設定情報を持たせなければならなくなってしまう
ためアプリケーション構成ファイルが採用できなくなってしまいました。

クラスライブラリで処理設定を保持するよな場合
どのような手法を取るのがベターなのでしょうか？

#私としては、独自定義したDLL設定ファイルとそれを扱うクラスを作成するしか無いのかなぁ？
#と、考えています。

引用返信 編集キー/

■8526 / inTopicNo.2)

　Re[1]: クラスライブラリで利用する設定の利用手法

▲▼■

□投稿者/ IIJIMAS (35回)-(2007/10/02(Tue) 12:54:29)

■No8525 (ふぇいさん) に返信
> この複数あるDLLに各々別の設定ファイルを持たせDLL処理内部で
> 利用させたく、単に各DLLプロジェクトのアプリケーション構成ファイル
> で設定を持たせDLLに利用させようと思っていました。

そんなイメージのサンプルを作られた方のページを発見しました。(.NET1.1みたいですが…)

Mike Woodring's .NET Sample Page
Per-Assembly Configuration Files
http://www.bearcanyon.com/dotnet/#AssemblySettings

引用返信 編集キー/

■8530 / inTopicNo.3)

　Re[2]: クラスライブラリで利用する設定の利用手法

▲▼■

□投稿者/ ふぇい (2回)-(2007/10/02(Tue) 14:35:16)

■No8526 (IIJIMAS さん) に返信

IIJIMASさんこんにちは。
お返事ありがとうございます。

> そんなイメージのサンプルを作られた方のページを発見しました。(.NET1.1みたいですが…)
>
> Mike Woodring's .NET Sample Page
> Per-Assembly Configuration Files
> http://www.bearcanyon.com/dotnet/#AssemblySettings
見つけて頂いた、ページ拝見しました。
DOM系のXMLパースを利用した独自読込方法なのですね。

今までDLL設定をアプリケーション構成ファイルとして、
作成を進めてきたのでこの設定を無駄にする事なく生かせそうです。

独自実装の場合の方法として検討してみます。
ありがとうございます。

DLLに設定ファイルっていうケースはあまり無いんでしょうか？
DLL自体に外部より設定したい！って事が私の場合多々あるんですけれども。。
あまりそんなプログラムを見た事が無いのでちょっと不安です。

引用返信 編集キー/

■8559 / inTopicNo.4)

　Re[3]: クラスライブラリで利用する設定の利用手法

▲▼■

□投稿者/ 渋木宏明(ひどり) (442回)-(2007/10/02(Tue) 23:59:01)

2007/10/03(Wed) 00:10:34 編集(投稿者)

> DLLに設定ファイルっていうケースはあまり無いんでしょうか？

プラグインのようなものの場合は「あり」だと思いますが、一般論的にはちょっと違和感を感じますね。

.dll は所詮単なる入れ物なので、それ自身が「設定」を必要とすることは無く、本来？「設定」を必要としているのは「.dll に収められているクラスたち」のはずです。

仮にプラグインを想定したとしても、プラグインの設定を「.dll と対応付けられたファイル」に記述「しなければならない」理由としてはそれほど強くないと思います。

アプリケーション本体と対応付けられたファイルに設定を記述し、それをアプリケーションが .dll （内のどれかのクラス）に引き渡す、という流れも考えられます。

また、「.exe の横」「.dll の横」は「Program Files 配下」であることが想定されます。

Program Files 配下に配置された設定ファイルの書き換えには管理者権限が必要ですし、Vista ではこの辺の制限が強化されています。

インストーラによる配布を行った場合、インストーラによって配置されたファイルを書き換えるというシナリオは、Windows Installer による「復旧」の仕組みとも相性がよくありません。

当たり前の話ですが、.dll と設定ファイルが１対１で対応付けられているということは、「ユーザ毎の設定」を格納するのにも向きません。

等々、れまでは「場合によってはあり得る」「無くは無い」形態だったと思いますが、今後を考えると避けるべきでしょう。

引用返信 編集キー/

■8565 / inTopicNo.5)

　Re[4]: クラスライブラリで利用する設定の利用手法

▲▼■

□投稿者/ ふぇい (4回)-(2007/10/03(Wed) 09:43:53)

■No8559 (渋木宏明(ひどり) さん) に返信

渋木さんこんにちは。

> .dll は所詮単なる入れ物なので、それ自身が「設定」を必要とすることは無く、
> 本来？「設定」を必要としているのは「.dll に収められているクラスたち」のはずです。

そうですね、今回作成しているDLLで必要とし、設定ファイルで渡す事としていた設定群も
DLLに収めている、ある処理を行う「クラスたち」で利用する物であり、
DLL自身が必要とはしていません。
単にDLL中でクラスに処理させる処理内容の設定という意味あいです。
私の説明不足でした、すみません。

> 仮にプラグインを想定したとしても、プラグインの設定を「.dll と対応付けられたファイル」に
> 記述「しなければならない」理由としてはそれほど強くないと思います。
> アプリケーション本体と対応付けられたファイルに設定を記述し、
> それをアプリケーションが .dll （内のどれかのクラス）に引き渡す、という流れも考えられます。

作成当初EXE→DLLへと引き渡す事も考えてみたのですが、
やはりプラグイン(のような物ですけども)だと作成時点で将来作成されるであろうのプラグインに
必要とする設定が、不明確な事もありDLL側に持たせたいと思った次第です。

>プラグインのようなものの場合は「あり」だと思いますが、一般論的にはちょっと違和感を感じますね。

> 等々、れまでは「場合によってはあり得る」「無くは無い」形態だったと思いますが、今後を考えると避けるべきでしょう。

プラグインとしてならば、まぁアリ。だけど現状から将来の環境の事考えたら良く無いよね。
って事なのですね。
Vistaをターゲットにしたプログラムになる予定なので、グサッときました。
もう少し設定形態について考えてみます。

ありがとうございました。

#WindowsInstallerでの復旧処理ってOrcaか何かで処理制限できませんでしたっけ・・・
#勘違いな雰囲気がいっぱいしますけども。。

引用返信 編集キー/

■8571 / inTopicNo.6)

　Re[5]: クラスライブラリで利用する設定の利用手法

▲▼■

□投稿者/ 渋木宏明(ひどり) (444回)-(2007/10/03(Wed) 11:44:05)

2007/10/03(Wed) 11:45:38 編集(投稿者)

> プラグインとしてならば、まぁアリ。だけど現状から将来の環境の事考えたら良く無いよね。
> って事なのですね。

そうですね。

プラグインみたいに運用形態が確立しているものなら、全ユーザ共通の「プラグインの設定」を「プラグインの .dll とノード名が同じ設定ファイル」に記述する、というのはそれほどマズイものではないと思います。これまでは。

んが、Vista はそれを容認しない方向です。

> Vistaをターゲットにしたプログラムになる予定なので、グサッときました。
> もう少し設定形態について考えてみます。

「設定」といってもイロイロな切り口があるので、

・構成情報（配置時・直後に管理者が設定、原則その後いじらない）
・全ユーザ共通の設定（管理者が設定）
・ユーザ毎の設定（各ユーザが設定）

に分類してみるといいんじゃないかと。

これが出来れば、おのずと「設定の格納先」を格納する場所が見えてきます。

> #WindowsInstallerでの復旧処理ってOrcaか何かで処理制限できませんでしたっけ・・・

いえ、出来なかったと思いますよ。
復旧付のアドバタイズショートカットをやめて、「普通の」ショートカットファイルにすることは出来ますが。

引用返信 編集キー/

■8574 / inTopicNo.7)

　Re[6]: クラスライブラリで利用する設定の利用手法

▲▼■

□投稿者/ とっちゃん (196回)-(2007/10/03(Wed) 12:54:09)

■No8571 (渋木宏明(ひどり) さん) に返信

>>#WindowsInstallerでの復旧処理ってOrcaか何かで処理制限できませんでしたっけ・・・
>
> いえ、出来なかったと思いますよ。
> 復旧付のアドバタイズショートカットをやめて、「普通の」ショートカットファイルにすることは出来ますが。
>
ここだけコメント。
普通の形式のショートカットでも、WindowsInstaller に作らせる場合(Shortcut Tableに配置)は、
復旧情報が付きます。
自分で、IShortcutLink から起こすという場合なら別ですけどｗ

引用返信 編集キー/

■8578 / inTopicNo.8)

　Re[7]: クラスライブラリで利用する設定の利用手法

▲▼■

□投稿者/ 渋木宏明(ひどり) (446回)-(2007/10/03(Wed) 13:47:15)

> 普通の形式のショートカットでも、WindowsInstaller に作らせる場合(Shortcut Tableに配置)は、
> 復旧情報が付きます。

そだっけ？ (^^;

やぱり、Windows Installer で直接的に配置した「ブツ」は全部復旧対象になってしまう、てことですね。

引用返信 編集キー/

■8579 / inTopicNo.9)

　Re[6]: クラスライブラリで利用する設定の利用手法

▲▼■

□投稿者/ ふぇい (5回)-(2007/10/03(Wed) 13:56:57)

■No8571 (渋木宏明(ひどり) さん) に返信

> 「設定」といってもイロイロな切り口があるので、
>
> ・構成情報（配置時・直後に管理者が設定、原則その後いじらない）
> ・全ユーザ共通の設定（管理者が設定）
> ・ユーザ毎の設定（各ユーザが設定）
>
> に分類してみるといいんじゃないかと。
>
> これが出来れば、おのずと「設定の格納先」を格納する場所が見えてきます。

そうですね。もう少し考えてみて方向性をある程度固めてみたいと思います。
#DLLに対する、全ユーザ共通の設定となりそうなので、
#hoge.dll hoge.configとか作って逃げてしまいそうですけども。。

>>#WindowsInstallerでの復旧処理ってOrcaか何かで処理制限できませんでしたっけ・・・
>
> いえ、出来なかったと思いますよ。
> 復旧付のアドバタイズショートカットをやめて、「普通の」ショートカットファイルにすることは出来ますが。

あら、やっぱり勘違いでした。
フォローありがとうございます。

いろいろと参考になりました。
ありがとうございました。

解決済み

引用返信 編集キー/

■8580 / inTopicNo.10)

　Re[8]: クラスライブラリで利用する設定の利用手法

▲▼■

□投稿者/ とっちゃん (198回)-(2007/10/03(Wed) 14:10:45)

■No8578 (渋木宏明(ひどり) さん) に返信
>>普通の形式のショートカットでも、WindowsInstaller に作らせる場合(Shortcut Tableに配置)は、
>>復旧情報が付きます。
>
> そだっけ？ (^^;
>
はい。WindowsInstaller のエンジンがやってくれる範囲内では、ばっちりつけてくれます。
＃IShellLink でも引っ張れないどこかなぞなところへですがｗ

> やぱり、Windows Installer で直接的に配置した「ブツ」は全部復旧対象になってしまう、てことですね。
>
です。
Feature 変えれば(Featureに連動なのでｗ)、回避できますけどｗ
VSのじゃぁできないですからねぇｗ

引用返信 編集キー/

■8581 / inTopicNo.11)

　Re[7]: クラスライブラリで利用する設定の利用手法

▲▼■

□投稿者/ ふぇい (7回)-(2007/10/03(Wed) 14:12:46)

■No8574 (とっちゃんさん) に返信
とっちゃんさん、こんにちは。

> 普通の形式のショートカットでも、WindowsInstaller に作らせる場合(Shortcut Tableに配置)は、
> 復旧情報が付きます。
> 自分で、IShortcutLink から起こすという場合なら別ですけどｗ

普通の形式でも復旧対象になってしまうんですね。
#普通の形式でショートカット作って、逃げてしまおうなんて思っていました。。

Installerによる復旧を踏まえ設定情報の持たせ方、考えてみます。
ありがとうございました。

#最近Installerを利用する予定があり、とっちゃんさんのブログよく拝見します。
#ためになってばかりです。更新がんばってくださ～い！

#Installerの話が出たので、もしかして・・・なんて思っていたのはナイショ。

解決済み

引用返信 編集キー/

トピック内ページ移動 / << 0 >>

このトピックに書きこむ

過去ログには書き込み不可

- Child Tree -