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

繰り返しになりますが、半角カナの投稿は控えてください。また混入していますよ。

■No73576 (S.Kos さん) に返信
> SQLConfigDataSourceの動作に関わる、単なる｢プログラマーとしての興味｣は残りますが
どの段階まで調査されたのかが良くわからなかったのですが、
「管理者として実行していなかった」というわけでもなく、また、今回の実行環境において、
文字列の内容が意図せず変質してしまっていた…という訳でもないのですね?


> 私が扱う環境は、いま暫くの間、64bitネイティブにほど遠いでしょう。
> けれど、いずれ来るその時に備えて、重ねてご教示いただければ幸いです。
本題からは外れますが、蛇足情報として：


32bit アプリの起動を目的とするなら、環境変数 PROCESSOR_ARCHITECTURE の判定だけでも良いですが、
64bit アプリの起動を目的とする場合には、それだけでは不十分です。システムフォルダを
正しく扱うためには、WOW64 動作になっていないかどうか、見極めが必要になります。


環境変数 PROCESSOR_ARCHITECTURE が "x86" を返してきた場合には、WOW64 動作の可能性があるため、
環境変数 PROCESSOR_ARCHITEW6432 も追加調査が必要であるという事です。

┏━━━━━━━━━━━┳━━━━━━━━━┯━━━┯━━━━━━━━━┓
┃      環境変数        ┃       64bit      │ 32bit│       WOW64      ┃
┣━━━━━━━━━━━╋━━━━━━━━━┿━━━┷━━━━━━━━━┫
┃PROCESSOR_ARCHITECTURE┃AMD64 または IA64 │           x86            ┃
┠───────────╂─────────┴───┬─────────┨
┃PROCESSOR_ARCHITEW6432┃        (未定義)          │AMD64 または IA64 ┃
┗━━━━━━━━━━━┻━━━━━━━━━━━━━┷━━━━━━━━━┛


64bit プロセスのコマンドプロンプトの場合、そのまま
C:\Windows\System32\ は 64bit 用のフォルダとなり、
C:\Windows\SysWOW64\ は 32bit 用のフォルダとなるわけですが、
これが WOW64 のコマンドプロンプトとなると意味が変わってきます。

64bit OS 上で、32bit 版のコマンドプロンプト(C:\Windows\SysWOW64\cmd.exe)を
実行した場合、C:\Windows\System32\ も C:\Windows\SysWOW64\ のいずれもが、
共に 32bit 用のフォルダを指し示す仕様です。いわゆるファイル システム リダイレクタです。

そして、WOW64 のコマンドプロンプトから、64bit のシステムフォルダを参照する場合は
「C:\Windows\SysNative\」というパスを利用することになります。
（このパスは、64bit プロセスからはアクセスできません）


>>runas 指定の呼び出しは、もっと冒頭に置いた方が良いかな…。
> この手のループをどこに置くか？　ってのは、

Do ループにせずとも、If 文で十分だと思います。
まぁ、参考にしたソースがそうなっていた、という事なのでしょうけれども。


> Ｃで書くWinmainのように、ある種の「お作法」でしょう。

作法というほど堅い話では無いです。その方が単に私の好みという程度の宗教論。
C 言語的なイメージコードで言うと、元のコードは

//------------------------------------------------
　　strCommand = odbcconfのコマンドラインを生成;   // ★
　　if(引数が0個だった場合) {
　　　管理者モードで再起動;  // 再起動の識別用に、ダミー引数 "uac"を 追加
　　　return;
　　}
　　strCommand のコマンドラインを実行;
//------------------------------------------------

という順序で処理されていますが、それを

//------------------------------------------------
　　if(引数が0個だった場合) {
　　　管理者モードで再起動;  // 再起動の識別用に、ダミー引数 "uac"を 追加
　　　return;
　　}
　　strCommand = odbcconfのコマンドラインを生成;   // ★
　　strCommand のコマンドラインを実行;
//------------------------------------------------

とした方が良いのでは無いかな、と思ったという程度です。
どうせ再起動してしまうのなら、その前にコマンドラインの準備をすすめたところで無意味なので。


ただ、それによる処理効率などの差は微々たるものです。今回のコードの主目的は
「odbcconf」の実行なのですから、それを目立たせるため、コマンドラインの設定を
あえてコードの先頭に書くようにするのも、方針としては悪くないと思います。


> 殆どが断片的な情報で、全景を見渡せるものがありませんでした。
> 世の大勢の「お作法」があれば、是非ご教示ください。
個々の断片を意図を把握しているなら、良し悪しはあれど、組み合わせは任意だと思いますよ。


作法という類の物では無いですが、余裕があれば、
「管理者として実行されているか」まで調査することもできます。

http://scripting.cocolog-nifty.com/blog/2010/01/post-f725.html
http://yozda.exblog.jp/19733454
http://qiita.com/skkzsh/items/5e03bb7792629927acfa


その上で、管理者実行でなかった場合には、自身を "RunAs" 指定で呼び出し、
管理者モードで呼び直すことになります。 No73570 のコードでは、
管理者実行されていているかの事前判定を省略して、
常に RunAs 指定で呼び直す形になっていますね。


その RunAs 指定の方法はいろいろありますが、VBScript の場合は、
既に利用されているように、ShellExecute メソッドで指定するのが簡単でしょう。

http://www.atmarkit.co.jp/fdotnet/dotnettips/954uacrunas/uacrunas.html
http://msdn.microsoft.com/ja-jp/library/cc781769.aspx

自身を呼び直した時は、それが再起動であることがわかるようにせねばなりませんが、
No73570 で書かれていたコードでは、任意の引数を加えることで識別されているようですね。

Hongliang さん

アドバイスありがとうございます。

            // USBコントローラの一覧に"STM Device in DFU Mode"があるか検索
            ManagementClass mcW32USBDevice = new ManagementClass("Win32_USBController");
            foreach (ManagementObject USBDevice in mcW32USBDevice.GetInstances())
            {
                sWrk = (USBDevice.GetPropertyValue("Caption")).ToString();
                if (sWrk.IndexOf("STM Device in DFU Mode") != -1)
                {
                    iWrk = 1;
                }
            }
            if (iWrk == 1)  // DFU Modeだったらエラー
            {
                // エラー処理書く
            }


に修正してやってみました。
テストしたところ、デバイスマネージャの「ユニバーサルシリアルバスコントローラー」の下層の項目の、
最初の２つは取れたのですが、デバイスマネージャ上は１１個の項目がぶら下がっているのですが、
            foreach (ManagementObject USBDevice in mcW32USBDevice.GetInstances())
のところで、３つ目の項目の処理がされずに、foreach () 文を抜けてしまいました。


デバイスマネージャのUSBコントローラーのツリー表示上では
「ユニバーサルシリアルバスコントローラー」
　　−　Intel(R) USB3.0 eXtensible Host Controller - 1.0(Microsoft)
　　−　Intel(R) USB3.1 eXtensible Host Controller - 1.10(Microsoft)
　　−　SafeNet USB SuperPro/UltraPro
　　−　STM 32 Device in DFU Mode
　　−　．．．
　　−　．．．
　　−　．．．

となっているのですが、上記のプログラムでは、foreach () ループ内を2回繰り返し、
sWrk に、「Intel(R) USB3.1 eXtensible Host Controller - 1.10(Microsoft)」と、
「Intel(R) USB3.1 eXtensible Host Controller - 1.10(Microsoft)」は代入されたのですが
３回目は回らずに、foreach () ループを抜けてしまいました。
foreach () 文のところ、記述間違っているでしょうか？
アドバイスいただけるとありがたいです。

shellメソッドとProcessクラスとで
スピードに大きな違いがあるのでしょうか？

以下のような環境で
プロセスA→プロセスCの処理を行うとプロセスCの起動〜終了
まで２０秒程度かかります。
プロセスC自体はそこまで時間のかかる処理を行っていないので
shellメソッドを使用することに問題があるのでは？
と思い調べては見ましたが、情報が見当たりませんでした。

何か情報等ございましたらご教示のほどよろしくお願いいたします。


●プロセスAの概要
・Exe形式(.NetFramework4.6でビルド)
・定周期でDBの監視を行い、プロセス起動要求があればshellメソッドを使用してプロセスCを起動

●プロセスBの概要
・Exe形式(.NetFramework4.6でビルド)
・要求されたプログラムをProcessクラスを使用してプロセスD起動

●プロセスCの概要
・Exe形式(.NetFramework4.6でビルド)
・OracleDataAccess.dllを使用してバッチ処理を行う。
・単体（デバッグ実行）で３秒程度で終了

●プロセスDの概要
・Exe形式(VB6で作成されたフォームアプリ)


●動作環境
OSバージョン：Windows Server2012
フレームワーク： .NetFramework4.6
ビルド環境：Visual Studio2015