tagCANDY CGI VBレスキュー(花ちゃん) の Visual Basic 2010 用 掲示板(VB.NET 掲示板) [ツリー表示へ]   [Home]
一括表示(VB.NET VB2005)
タイトルMy.Settingはプロジェクト独立?
記事No5703
投稿日: 2007/06/25(Mon) 12:09
投稿者ダンボ
VB2005勉強中です。
>VB6からの移行時にソリューショ.. - ダンボ 07/06/20-13:19 No.5665
の続きです。無事一つのソリューションとしてソース書き直し中ですが、

「IniファイルはMy.Settingに移行する」方針で躓いています。

3つのプロジェクトDirectGo、DirectGoP、DirectGoEでは共通にDirectGo.Iniファイルを
アクセスして連携を取ります。どうもMy.Settingだとプロジェクト毎に設定されるようなので
この利用ができません?

My.Settingをあきらめて共通Iniファイルで続行すべきか、それともMy.Settingの利用が
できるのかどうかお教え下さい。

[ツリー表示へ]
タイトルRe: My.Settingはプロジェクト独立?
記事No5706
投稿日: 2007/06/25(Mon) 13:33
投稿者よねKEN
方針としては既存のソースコードをできる限り直さないという方針なのでしょうか?
それとも必要に応じて.NETらしい形にしようという方針でしょうか?
#期限、費用などによるでしょうけど

> 3つのプロジェクトDirectGo、DirectGoP、DirectGoEでは共通にDirectGo.Iniファイルを
> アクセスして連携を取ります。どうもMy.Settingだとプロジェクト毎に設定されるようなので
> この利用ができません?

DirectGo、DirectGoP、DirectGoEの3つのプロジェクトの関係がよくわかりません。
http://hanatyan.sakura.ne.jp/vbnetbbs/wforum.cgi?no=5665&reno=no&oya=5665&mode=msgview&page=0

を見るとそれぞれが独立したexeのようですが、
別々に起動する必要があって別々のexeになっているのでしょうか?

各プロジェクトの概要やそれぞれの役割は何でしょうか?
その辺の背景がわかりませんが、現行のソースの作りに固執する必要がなければ、
場合によってはプロジェクト構成から見直すという手もあるかもしれません。
それによりもっと別の方法もあるかもしれません。

> My.Settingをあきらめて共通Iniファイルで続行すべきか、それともMy.Settingの利用が
> できるのかどうかお教え下さい。

My.Settingが使えなさそうなのであれば、
XmlSerializer(System.Xml.Serialization.XmlSerializerクラス)を使ってみるとか。

[ツリー表示へ]
タイトルRe^2: My.Settingはプロジェクト独立?
記事No5707
投稿日: 2007/06/25(Mon) 14:29
投稿者ダンボ
よねKENさん、お世話になっています。

> 方針としては既存のソースコードをできる限り直さないという方針なのでしょうか?

勉強のためです。方針としては既存の基本仕様(アイデア)のみを活かしてソースコードは
できる限り.NETらしい形にします。期限はいくらかかってもいいです。


> DirectGo、DirectGoP、DirectGoEの3つのプロジェクトの関係がよくわかりません。
> 別々に起動する必要があって別々のexeになっているのでしょうか?

・DirectGo.exe…タスクバー常駐でユーザからクリックされるのを待っています。可能な限りリソースを削っています。
・DirectGoE.exe…DirectGo.exeから起動されて指示された仕事をします。なるべく軽く動作します。
・DirectGoP.exe…このシステムの諸設定をします。一番リソースを食っていますがめったに動かしません。


> My.Settingが使えなさそうなのであれば、
> XmlSerializer(System.Xml.Serialization.XmlSerializerクラス)を使ってみるとか。

勉強のためなので、意地でもiniファイルはやめましょう。レジストリかXMLか。
ところが、これは共通サーバーに置いて複数クライアントから呼ぶこともあるので、
レジストリだと速度は良いとしても管理が複雑になりそうです。

(*)My.Settingの実体を探ると、
 My Project\Settings.Designer.vb
 My Project\Settings.settings
なので、Common.Vb同様にこれの場所を移して.vbprojファイルの編集で誤魔化せないかな?

[ツリー表示へ]
タイトルRe^3: My.Settingはプロジェクト独立?
記事No5708
投稿日: 2007/06/25(Mon) 15:26
投稿者魔界の仮面弁士
設定画面を用意するなら、「BinaryFormatter」を使うのも手。

> レジストリかXMLか。
とすれば、「XmlSerializer」か「XmlTextReader」あたりかな?

> ところが、これは共通サーバーに置いて複数クライアントから呼ぶこともあるので、
> レジストリだと速度は良いとしても管理が複雑になりそうです。
それって、設定項目だけを共通サーバに置くのですか?
それとも、exe ファイルも共通サーバに置きますか?

[ツリー表示へ]
タイトルRe^4: My.Settingはプロジェクト独立?
記事No5711
投稿日: 2007/06/25(Mon) 21:36
投稿者ダンボ
魔界の仮面弁士 さん、ありがとうございます

「BinaryFormatter」「XmlSerializer」「XmlTextReader」を調べていきます。

> それって、設定項目だけを共通サーバに置くのですか?
> それとも、exe ファイルも共通サーバに置きますか?

現状の使い方は、exe ファイルも設定項目も共通サーバで共同利用していますが、
今後の使われ方では、exe ファイルは共同、設定はクライアント毎です。
exe ファイルが共通なのはバグフィックス時に再配布不要だから。
設定は共通な部分も多いけれど、基本的には個人毎に異なるので。

[ツリー表示へ]
タイトルRe^5: My.Settingはプロジェクト独立?
記事No5715
投稿日: 2007/06/25(Mon) 22:37
投稿者魔界の仮面弁士
> 現状の使い方は、exe ファイルも設定項目も共通サーバで共同利用していますが、

その場合、System.Security.SecurityException が起きないよう、配慮が必要かと。

サーバ上に配置した exe を実行する場合、アクセス制限が厳しくなりますので…。
(たとえば、APIが使用できない/レジストリ項目の読み込みができないなど)

[ツリー表示へ]
タイトルRe^3: My.Settingはプロジェクト独立?
記事No5709
投稿日: 2007/06/25(Mon) 15:36
投稿者よねKEN
> > DirectGo、DirectGoP、DirectGoEの3つのプロジェクトの関係がよくわかりません。
> > 別々に起動する必要があって別々のexeになっているのでしょうか?
>
> ・DirectGo.exe…タスクバー常駐でユーザからクリックされるのを待っています。可能な限りリソースを削っています。
> ・DirectGoE.exe…DirectGo.exeから起動されて指示された仕事をします。なるべく軽く動作します。
> ・DirectGoP.exe…このシステムの諸設定をします。一番リソースを食っていますがめったに動かしません。

個別には起動することがないのであれば、
DirectGoE.exe、DirectGoP.exeは両方ともdllにしてしまって、
DirectGo.exeから参照設定して使うようにすれば、
設定情報を読み込むのはDirectGo.exeのみでよく、
DirectGoE.dll、DirectGoP.dllはそこから情報をもらえば良いのではないでしょうか?
  
> > My.Settingが使えなさそうなのであれば、
> > XmlSerializer(System.Xml.Serialization.XmlSerializerクラス)を使ってみるとか。

Xmlを簡単に扱える方法としてXmlSerializerを挙げております。
My.Settingは使ったことはありませんが、XmlSerializerを使う場合も
Xmlであることを意識する必要はほとんどないので扱いはとても簡単です

[ツリー表示へ]
タイトルRe^4: My.Settingはプロジェクト独立?
記事No5712
投稿日: 2007/06/25(Mon) 21:49
投稿者ダンボ
よねKENさん、どうもありがとうございます。

dllかぁ。それは考えたことが無かったです。
ただ、dll化しても、1dll=1プロジェクトなのでは無いですか?
DirectGo.exeからDirectGoE.dllに情報を渡すときは具体的にはどういう手が?

> XmlSerializerを使う場合も
> Xmlであることを意識する必要はほとんどないので扱いはとても簡単です

XMLは使いこなせるようにならんといかんと思っていますので、今回はこれで
実現しようと思います。

[ツリー表示へ]
タイトルRe^5: My.Settingはプロジェクト独立?
記事No5718
投稿日: 2007/06/25(Mon) 23:54
投稿者もねを
現在作成している内容なのですが私のほうではこのようにしています。
良いか悪いかわかりませんが初めてのVB2005だったもので・・・
しかし後ほどxmlの存在を知ってちょっとしまったーと少し思っていたりします。

私のほうでは、
ソリューションの中に3つのプロジェクトが存在します。今後はまだまだ増えます。
メインのexeで使用するsettingを他のexeでも使用しています。

exeを呼ぶときにコマンドラインを使用して渡したい項目を1つの文字列にして渡しています。
呼び出されたexeはコマンドラインを分解して項目に分けています。
コマンドライン用のクラスなんかを作ったのでやっかいでした。
シンプルな管理であればxmlをしようしたりiniを使用するほうが良いかと思います。

[ツリー表示へ]
タイトルRe^6: My.Settingはプロジェクト独立?
記事No5719
投稿日: 2007/06/26(Tue) 05:47
投稿者ダンボ
もねを さん、こんにちは

> exeを呼ぶときにコマンドラインを使用して渡したい項目を1つの文字列にして渡しています。

コマンドライン利用ですね。検討の価値ありです。
・デバッグのとき、DOS窓から直接呼び出せる
・特にDirectGoからDirectGoEを呼び出すときにはしっくりするインターフェースです。

> 呼び出されたexeはコマンドラインを分解して項目に分けています。
> コマンドライン用のクラスなんかを作ったのでやっかいでした。

GetCommandLineArgsやMy.Application.CommandLineArgsが用意されているみたいですよ。
コマンドライン作る方は、Join一発だし。

[ツリー表示へ]
タイトルRe^5: My.Settingはプロジェクト独立?
記事No5720
投稿日: 2007/06/26(Tue) 09:27
投稿者よねKEN
> dllかぁ。それは考えたことが無かったです。

念のための補足ですが、dllというとWindows APIのような標準DLLと
VB6でも作成できるActiveX DLLがありますが、.NETのdllはそれらとは別物です。

しいて言うなら、ActiveX DLLに近いものと考えていただければよいかと思います。

> ただ、dll化しても、1dll=1プロジェクトなのでは無いですか?

1dllは1プロジェクトです。

> DirectGo.exeからDirectGoE.dllに情報を渡すときは具体的にはどういう手が?

VB6のActiveX DLLを使うのと同じ感覚ですね。
DLLを参照設定します。するとEXEからはDLLのクラスのインスタンスを生成できます。

つまり、DirectGoにFormAがあって、DirectGoEにFormBがあるとして、
DirectGoのFormAのボタンのクリックイベントに、
frmB = New FormB()
frmB.Show()
のように記述することでFormBを表示できます。
プロパティもメソッドもイベントも同様に使えますので、単独のEXEで処理する場合と大差ありません。
プロパティなどを介してデータを受け渡します。

#実際にはデータの受け渡し用のクラスはDirectGo、DirectGoE、DirectGoPの
#すべてが知っている必要がありそうですから、受け渡し用のクラスを含む別のDLLを用意
#することになるかもしれません。

> > XmlSerializerを使う場合も
> > Xmlであることを意識する必要はほとんどないので扱いはとても簡単です
>
> XMLは使いこなせるようにならんといかんと思っていますので、今回はこれで
> 実現しようと思います。

ファイルを介してデータを受け渡す場合は、異なるexe/dll間でデータの受け渡しをする場合に
ファイルの内容を改ざんされた場合について考慮が必要かもしれませんので、
その点は注意が必要です。
#元々iniファイルでやりとりしていたということですので、
#ファイルの改ざんまでは考慮しないという決めがあるのだと思いますが

[ツリー表示へ]
タイトル[解決]My.Settingはプロジェクト独立?
記事No5722
投稿日: 2007/06/26(Tue) 13:44
投稿者ダンボ
よねKEN さん、魔界の仮面弁士 さん、もねを さん 
色々アイデアをいただきありがとうございました。


スレッド題名に対する答えはYes[My.Settingはプロジェクトごとに独立]。

> My.Settingの実体を探ると、
> My Project\Settings.Designer.vb
>  My Project\Settings.settings
> なので、Common.Vb同様にこれの場所を移して.vbprojファイルの編集で誤魔化せないかな?

の答えは得られませんでしたが、まあやめときます。My.Settingって結局XMLファイルを
簡単に更新する仕掛けですよね。XMLそのものに習熟したいのでもう少しBasicなクラスを
利用してみます。

よねKEN さんご提案の「受け渡し用のクラス」、今後の新規プログラムでは考えてみたいところ。

[ツリー表示へ]