VB2005勉強中です。
＞VB6からの移行時にソリューショ.. - ダンボ 07/06/20-13:19 No.5665
の続きです。無事一つのソリューションとしてソース書き直し中ですが、

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

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

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

方針としては既存のソースコードをできる限り直さないという方針なのでしょうか？
それとも必要に応じて.NETらしい形にしようという方針でしょうか？
＃期限、費用などによるでしょうけど

> ３つのプロジェクト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クラス)を使ってみるとか。

よねＫＥＮさん、お世話になっています。

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

勉強のためです。方針としては既存の基本仕様（アイデア）のみを活かしてソースコードは
できる限り.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ファイルの編集で誤魔化せないかな？

設定画面を用意するなら、「BinaryFormatter」を使うのも手。

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

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

魔界の仮面弁士 さん、ありがとうございます

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

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

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

> 現状の使い方は、exe ファイルも設定項目も共通サーバで共同利用していますが、

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

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

> > 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であることを意識する必要はほとんどないので扱いはとても簡単です

よねＫＥＮさん、どうもありがとうございます。

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

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

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

現在作成している内容なのですが私のほうではこのようにしています。
良いか悪いかわかりませんが初めてのVB2005だったもので・・・
しかし後ほどxmlの存在を知ってちょっとしまったーと少し思っていたりします。

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

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

もねを さん、こんにちは

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

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

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

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

> 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ファイルでやりとりしていたということですので、
＃ファイルの改ざんまでは考慮しないという決めがあるのだと思いますが

よねＫＥＮ さん、魔界の仮面弁士 さん、もねを さん　
色々アイデアをいただきありがとうございました。


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

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

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

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