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

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

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

Re[15]: 実行中のプロセス取得について

(過去ログ 121 を表示中)

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

■72346 / inTopicNo.1)

　実行中のプロセス取得について

▼■

□投稿者/ nobb (30回)-(2014/06/05(Thu) 09:30:28)

分類:[C/C++]　

プログラム中で現在実行されているプロセス(正確には実行ファイル名)を取得したいと思い調べてみると
PSAPIを使用する方法が見つかりました。

そこで開発環境にVisualStudioがインストールされているので、ヘッダー・ライブラリもあるのでは？と
検索をしてみると沢山でてきてしまい、どれを使えばいいのか分からないのでお教え下さい。
また配布するDLLはSystemフォルダのものでいいのでしょうか？

大変わずらわしいかと思いますがよろしくお願いします。

開発環境：Win7、VisualStudio2013(ただし、VS2008・VS2010インストール済み)、C++(MFC)
対象環境：WinXP以上(VISTA以上は32bit、64bit両方)

== 以下PSAPIを検索して見つけたファイル ==
1. C:\Program Files (x86)\Microsoft SDKs\Windows\v5.0\Include\Psapi.h
2. C:\Program Files (x86)\Microsoft SDKs\Windows\v5.0\Lib\IA64\Psapi.Lib
3. C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Include\Psapi.h
4. C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\IA64\Psapi.Lib
5. C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\Psapi.Lib
6. C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\x64\Psapi.Lib
7. C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Include\Psapi.h
8. C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Lib\Psapi.Lib
9. C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Lib\x64\Psapi.Lib
10. C:\Program Files (x86)\Windows Kits\8.0\Include\um\Psapi.h
11. C:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\x64\Psapi.Lib
12. C:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\x86\Psapi.Lib
13. C:\Program Files (x86)\Windows Kits\8.1\Include\um\Psapi.h
14. C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x64\Psapi.Lib
15. C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x86\Psapi.Lib
16. C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include\Psapi.h
17. C:\Program Files\Microsoft SDKs\Windows\v6.0A\Lib\Psapi.Lib
18. C:\Program Files\Microsoft SDKs\Windows\v6.0A\Lib\x64\Psapi.Lib
19. C:\Program Files\Microsoft SDKs\Windows\v7.1\Include\Psapi.h
20. C:\Program Files\Microsoft SDKs\Windows\v7.1\Lib\IA64\Psapi.Lib
21. C:\Program Files\Microsoft SDKs\Windows\v7.1\Lib\Psapi.Lib
22. C:\Program Files\Microsoft SDKs\Windows\v7.1\Lib\x64\Psapi.Lib
23. C:\Windows\System32\psapi.dll
24. C:\Windows\SysWOW64\psapi.dll
25. C:\Windows\winsxs\amd64_microsoft-windows-basedependencies_31bf3856ad364e35_6.1.7600.16385_none_5e96e36b42806ee7\psapi.dll
26. C:\Windows\winsxs\Backup\amd64_microsoft-windows-basedependencies_31bf3856ad364e35_6.1.7600.16385_none_5e96e36b42806ee7_psapi.dll_e8b5b4d1
27. C:\Windows\winsxs\Backup\x86_microsoft-windows-basedependencies_31bf3856ad364e35_6.1.7600.16385_none_027847e78a22fdb1_psapi.dll_e8b5b4d1
28. C:\Windows\winsxs\x86_microsoft-windows-basedependencies_31bf3856ad364e35_6.1.7600.16385_none_027847e78a22fdb1\psapi.dll

引用返信 編集キー/

■72353 / inTopicNo.2)

　Re[1]: 実行中のプロセス取得について

▲▼■

□投稿者/ 774RR (159回)-(2014/06/05(Thu) 12:33:03)

使う VS に付属のヘッダやライブラリを使うといい。変な設定はいらないよ。
psapi.dll は配布しちゃダメだぞ。そもそも配布不要だし。

引用返信 編集キー/

■72354 / inTopicNo.3)

　Re[1]: 実行中のプロセス取得について

▲▼■

□投稿者/ とっちゃん (222回)-(2014/06/05(Thu) 13:20:47)

■No72346 (nobb さん) に返信

すでに返答ついてるけどせっかく書いたから張り付けておこうｗ

> プログラム中で現在実行されているプロセス(正確には実行ファイル名)を取得したいと思い調べてみると
> PSAPIを使用する方法が見つかりました。
>
自分自身のプロセスが知りたいのですか？
それとも、タスクマネージャのように実行中のプロセスをすべてリストアップですか？

> そこで開発環境にVisualStudioがインストールされているので、ヘッダー・ライブラリもあるのでは？と
> 検索をしてみると沢山でてきてしまい、どれを使えばいいのか分からないのでお教え下さい。

そういう時は、まずリファレンスを当たりましょう。
PSAPI でMSDNライブラリを検索(ローカルには、WindowsSDKのリファレンスが落とせないので、Webで検索)すると
http://msdn.microsoft.com/en-us/library/windows/desktop/ms684884(v=vs.85).aspx
というページにたどり着けます。

他にも実行中のプロセスのリストアップなら、Tool Help Library を利用するという方法もあります。
上記リンクの一つ上の Diagnostics に分類があります。

> また配布するDLLはSystemフォルダのものでいいのでしょうか？
>
再配布していいモジュールは、VS2013 なら、
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\redist の
Debug_NonRedist 以外のフォルダにあるファイルと
必須コンポーネント(VSセットアップはなくなっていますが、ClickOnceがあるので必須コンポーネントは残っています)
および、VSがインストールするマージモジュールの利用による間接参照の３種となります。

それ以外のものは、配布可能とはなっていません。

> == 以下PSAPIを検索して見つけたファイル ==

こちらについては、VSが複数入っているので、その分だけヘッダーやライブラリがあるということです。
VSの設定が壊れていなければ何もしなくても、自動的に環境にあったヘッダーやライブラリが参照されるので
こちらについてはあまり深く考えなくてもいいと思います。

まぁ、なんでたくさんあるのか？とか、それぞれのフォルダについてる数値や文字の意味だとかが知りたいというのなら
それはそれで調べるなり、質問してみるなりすればいいと思いますよ。
(5.0AとかのAにも意味があるんで)

引用返信 編集キー/

■72358 / inTopicNo.4)

　Re[2]: 実行中のプロセス取得について

▲▼■

□投稿者/ nobb (31回)-(2014/06/05(Thu) 14:34:54)

■No72353 (774RR さん) に返信
ご回答ありがとうございます。

試したところインクルードさえすれば使える事がわかりました。
おかげ様で変な設定をせずに済みました。

引用返信 編集キー/

■72359 / inTopicNo.5)

　Re[2]: 実行中のプロセス取得について

▲▼■

□投稿者/ nobb (32回)-(2014/06/05(Thu) 14:46:45)

■No72354 (とっちゃんさん) に返信
ご回答ありがとうございます。

> 自分自身のプロセスが知りたいのですか？
> それとも、タスクマネージャのように実行中のプロセスをすべてリストアップですか？
一応目的としては、アップデーターの起動時に対象プログラムが起動している場合は、
何かしらの方法(←考え中)でユーザーに伝え終了を促す、という事をしたい為、
実行中のプロセスを取得し、その中に対象プログラム(exe名での判断)があったら
「○○が起動しています。終了させて下さい」というメッセージ的なものを表示したいと考えていました。

> そういう時は、まずリファレンスを当たりましょう。
> PSAPI でMSDNライブラリを検索(ローカルには、WindowsSDKのリファレンスが落とせないので、Webで検索)すると
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms684884(v=vs.85).aspx
> というページにたどり着けます。
ぐぐるとこちらには行けなかったです。(検索結果の下過ぎて見てないかも・・・)
直接MSDNを検索した方がよさそうな気がしてきました！

> 他にも実行中のプロセスのリストアップなら、Tool Help Library を利用するという方法もあります。
Tool Help LibraryとPSAPI両方共プロセスの取得が出来るというブログがよくありますが、
何がどう違って、どういう時に使い分けるのかが分かりません。
もしお手数ではなければお教えいただけませんか？

> 再配布していいモジュールは、VS2013 なら、
> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\redist の
> Debug_NonRedist 以外のフォルダにあるファイルと
> 必須コンポーネント(VSセットアップはなくなっていますが、ClickOnceがあるので必須コンポーネントは残っています)
> および、VSがインストールするマージモジュールの利用による間接参照の３種となります。
>
> それ以外のものは、配布可能とはなっていません。
これは知りませんでしたので、覚えておきます。

> (5.0AとかのAにも意味があるんで)
こちらは問題の先送りにします。今お聞きしても忘れてしまいそうなので、
未来の自分が困った時にまた質問するかと思います！

引用返信 編集キー/

■72365 / inTopicNo.6)

　Re[3]: 実行中のプロセス取得について

▲▼■

□投稿者/ とっちゃん (223回)-(2014/06/05(Thu) 16:43:04)

■No72359 (nobb さん) に返信
> ■No72354 (とっちゃんさん) に返信
> ご回答ありがとうございます。
>
>>自分自身のプロセスが知りたいのですか？
>>それとも、タスクマネージャのように実行中のプロセスをすべてリストアップですか？
> 一応目的としては、アップデーターの起動時に対象プログラムが起動している場合は、
> 何かしらの方法(←考え中)でユーザーに伝え終了を促す、という事をしたい為、
> 実行中のプロセスを取得し、その中に対象プログラム(exe名での判断)があったら
> 「○○が起動しています。終了させて下さい」というメッセージ的なものを表示したいと考えていました。
>
インストーラのテクノロジ(エンジン)に何を使っているかで変わりますが
もし、Windows Installer(msi形式のインストーラ)で作っているのなら
アップデータがお任せで全部やってくれますよ？

VS2012 以上だと、IS(有償版または、無償版のLE)かWiXくらいしか選択肢がありませんけど。

>
>>そういう時は、まずリファレンスを当たりましょう。
>>PSAPI でMSDNライブラリを検索(ローカルには、WindowsSDKのリファレンスが落とせないので、Webで検索)すると
>>http://msdn.microsoft.com/en-us/library/windows/desktop/ms684884(v=vs.85).aspx
>>というページにたどり着けます。
> ぐぐるとこちらには行けなかったです。(検索結果の下過ぎて見てないかも・・・)
> 直接MSDNを検索した方がよさそうな気がしてきました！
>
リファレンスを当たる(から探す)といわれた場合、プライマリリファレンスを指しますので
MSDNを検索するということを意味します(広い範囲での検索は、よりピンポイントに情報を探す形じゃないと
雑音が多すぎて探し切れなくなるため)。
それがWebであるか、ローカルなヘルプビュワーであるかは原則としては考慮しないのですが
残念ながら、現在は Windows の API をローカルなヘルプビュワーにインストールできないため
基本Web上で検索となります(VS2010にAPIリファレンスを入れてればローカル検索可能)。

ちなみに、上記のURLは、直接検索結果ではなく、APIから逆引き(PSAPIのAPIを適当に検索して、リファレンスを開いて
そこからツリーを上にたどってルート部分を引いた)したものです。

紹介するような場合はそのほうが早いんでｗ

>
>>他にも実行中のプロセスのリストアップなら、Tool Help Library を利用するという方法もあります。
> Tool Help LibraryとPSAPI両方共プロセスの取得が出来るというブログがよくありますが、
> 何がどう違って、どういう時に使い分けるのかが分かりません。
> もしお手数ではなければお教えいただけませんか？
>
出自が違うだけで、どちらも似たようなことができるAPIセットです。
何がどう違っているかは、それぞれの About Xxx を参照してください。
そこに詳しく書かれています。

一応。。。現行OSは、NT系なので、ToolHelpではできないことでもPSAPIならできることは多々あります。
(多分逆はないと思いますが、わかりません)。

>
>>再配布していいモジュールは、VS2013 なら、
>>C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\redist の
>>Debug_NonRedist 以外のフォルダにあるファイルと
>>必須コンポーネント(VSセットアップはなくなっていますが、ClickOnceがあるので必須コンポーネントは残っています)
>>および、VSがインストールするマージモジュールの利用による間接参照の３種となります。
>>
>>それ以外のものは、配布可能とはなっていません。
> これは知りませんでしたので、覚えておきます。
>
一応。。。VC\redist の内容は無条件にコピーしていいわけではありません。

ここにあるランタイムDLLをインストーラでインストールする場合は、
msm を使うか(C:\Program Files (x86)\Common Files\Merge Modulesにある)
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\redist\1041\vcredist_x64.exe"
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\redist\1041\vcredist_x86.exe"
で、別途ランタイムインストーラを実行するかのいずれかになります。
前者を利用する場合は、ISあるいは、WiXなどでmsiを作ります(VS2010を使ってVSセットアップで作る方法もあり＜Nativeアプリに限る)。
＃vcredist_arm.exe を、ユーザー環境で利用することはデスクトップが解放されていない現状ではありません。

個々にあるランタイムを直接利用するのは、CD上のランチャーアプリなどインストールしないで、ユーザー環境で実行させる場合と
テスト環境に一時的にコピーする(ランタイムをわざとシステムに入れずにデバッグする、あるいはデバッグ版を利用してリモートデバッグするなど)という場合だけです。

引用返信 編集キー/

■72367 / inTopicNo.7)

　Re[4]: 実行中のプロセス取得について

▲▼■

□投稿者/ nobb (33回)-(2014/06/05(Thu) 17:17:26)

2014/06/05(Thu) 17:20:03 編集(投稿者)

■No72365 (とっちゃんさん) に返信
ご回答ありがとうございます。

> インストーラのテクノロジ(エンジン)に何を使っているかで変わりますが
> もし、Windows Installer(msi形式のインストーラ)で作っているのなら
> アップデータがお任せで全部やってくれますよ？
ISを使ってインストールはしているんですが、過去の作成者(?)が恐らくGUIDの事を知らずに作っていた(ような形跡)なので
メジャーアップデートにしろ、マイナーにしろできないと思っています。(私の認識に間違いがなければ・・・)
顧客毎に製品GUID(でしたっけ？)が「ひっちゃかめっちゃか」なおかつ、(お恥ずかしいので伏せますが)とある事情により対象を特定できません。
というISを使ってる利点の内、半分くらいを無駄にしている状態です。。。
なので、ゴリゴリアップデートをとるしかありません。

> リファレンスを当たる(から探す)といわれた場合、プライマリリファレンスを指しますので
> MSDNを検索するということを意味します
そうなんですね。。完全に「検索＝ぐぐる」という認識でした。
以後気を付けます。

> 一応。。。現行OSは、NT系なので、ToolHelpではできないことでもPSAPIならできることは多々あります。
> (多分逆はないと思いますが、わかりません)。
ありがとうございます！ひとまずPSAPIで推し進めていきます！
違いについては暇な時間に(or気分転換に)調べてみたいと思います！

> 一応。。。VC\redist の内容は無条件にコピーしていいわけではありません。
>
> ここにあるランタイムDLLをインストーラでインストールする場合は、
> msm を使うか(C:\Program Files (x86)\Common Files\Merge Modulesにある)
> "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\redist\1041\vcredist_x64.exe"
> "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\redist\1041\vcredist_x86.exe"
> で、別途ランタイムインストーラを実行するかのいずれかになります。
> 前者を利用する場合は、ISあるいは、WiXなどでmsiを作ります(VS2010を使ってVSセットアップで作る方法もあり＜Nativeアプリに限る)。
> ＃vcredist_arm.exe を、ユーザー環境で利用することはデスクトップが解放されていない現状ではありません。
>
> 個々にあるランタイムを直接利用するのは、CD上のランチャーアプリなどインストールしないで、ユーザー環境で実行させる場合と
> テスト環境に一時的にコピーする(ランタイムをわざとシステムに入れずにデバッグする、あるいはデバッグ版を利用してリモートデバッグするなど)という場合だけです。
配布に対する基準はあったんですね。
お教え頂きありがとうございます。

== ふと疑問に思ったので追記 ==
私の返信は引用多すぎでしょうか？
回答をいただいたらその部分に対して私の考えを書くっていう方法なんですが、
無駄にスレを伸ばしてしまっているような気がして・・・

引用返信 編集キー/

■72369 / inTopicNo.8)

　Re[5]: 実行中のプロセス取得について

▲▼■

□投稿者/ 774RR (161回)-(2014/06/05(Thu) 17:45:00)

オレオレアプリの起動中にオレオレアップデータを待たせる目的なら
俗に「多重起動防止」と呼ばれている方法で、アプリの起動状態をアップデータで知ると楽。
例: http://dobon.net/vb/dotnet/process/checkprevinstance.html
例: http://d.hatena.ne.jp/cjohn/20081204/1228397004

引用返信 編集キー/

■72371 / inTopicNo.9)

　Re[5]: 実行中のプロセス取得について

▲▼■

□投稿者/ とっちゃん (224回)-(2014/06/05(Thu) 19:00:14)

■No72367 (nobb さん) に返信
>>インストーラのテクノロジ(エンジン)に何を使っているかで変わりますが
>>もし、Windows Installer(msi形式のインストーラ)で作っているのなら
>>アップデータがお任せで全部やってくれますよ？
> ISを使ってインストールはしているんですが、過去の作成者(?)が恐らくGUIDの事を知らずに作っていた(ような形跡)なので
> メジャーアップデートにしろ、マイナーにしろできないと思っています。(私の認識に間違いがなければ・・・)
> 顧客毎に製品GUID(でしたっけ？)が「ひっちゃかめっちゃか」なおかつ、(お恥ずかしいので伏せますが)とある事情により対象を特定できません。
> というISを使ってる利点の内、半分くらいを無駄にしている状態です。。。
> なので、ゴリゴリアップデートをとるしかありません。
>
ISを使ってということですが、形式は何でしょう？
どの形式にせよ、一度試してみて本当に自前処理の必要があるかを確認してみることをお勧めします。

InstallScript 形式は、バージョンによって挙動どころか動作仕様が大きく違っているなどがあるので
前のバージョンではできなかったから。。。と決めつけていると、悲しい現実に遭遇することがあります。

インストーラエンジンがフォローしてくれないのであれば、改めて自前処理を実装するか
インストーラエンジンから検討しなおすかを考えればいいと思います。

ちなみに、MSI形式で作っている場合ですが、自身が更新するEXEあるいはDLLがロードされていれば
そのロードしているプロセスが誰かなどお構いなしに利用中のダイアログを出してくれます。

プラグインとかだと、そのインストーラから見たら見知らぬプロセスがロードしてるのに
このアプリが利用中って出ますよ。

> == ふと疑問に思ったので追記 ==
> 私の返信は引用多すぎでしょうか？

全文引用じゃないから問題ないかとｗ

> 回答をいただいたらその部分に対して私の考えを書くっていう方法なんですが、
> 無駄にスレを伸ばしてしまっているような気がして・・・

自分なりの考えを書くというのはいいと思います。
回答側が気付かなかったことがあるかもしれませんし、もしかしたらそうやって続けていくことで
新たなひらめきなどがあるかもしれません。

回答側とて何でも知っているというわけではありませんからね。
基本的には一般的にはこういうのじゃない?というところを経験などで補って文章書いてることが多いです。

引用返信 編集キー/

■72382 / inTopicNo.10)

　Re[6]: 実行中のプロセス取得について

▲▼■

□投稿者/ nobb (34回)-(2014/06/06(Fri) 09:08:17)

■No72369 (774RR さん) に返信
> オレオレアプリの起動中にオレオレアップデータを待たせる目的なら
> 俗に「多重起動防止」と呼ばれている方法で、アプリの起動状態をアップデータで知ると楽。
二重起動防止について、今まで必要に迫られる事がなかったので、うっすらとした知識しかないのですが、
A.exeが(別途起動された)A.exe自身から見て既に起動しているか？という事が出来るという認識しかありません。

A.exeを起動中にUpdater.exeからA.exeが起動しているかどうかを確認できるという事なのでしょうか？

引用返信 編集キー/

■72384 / inTopicNo.11)

　Re[6]: 実行中のプロセス取得について

▲▼■

□投稿者/ nobb (35回)-(2014/06/06(Fri) 09:32:52)

■No72371 (とっちゃんさん) に返信
> ISを使ってということですが、形式は何でしょう？
> どの形式にせよ、一度試してみて本当に自前処理の必要があるかを確認してみることをお勧めします。
形式は基本MSIです。
InstallScript形式は使っていません。
ちなみに使用しているISのバージョンはIS2011Proです。

> インストーラエンジンから検討しなおすかを考えればいいと思います。
エンジンからということは、そもそもMSIから見直すという事ですか？
WindowsのインストーラーはMSIのみだと勝手思っていますが、他のエンジンもあるのでしょうか？

> ちなみに、MSI形式で作っている場合ですが、自身が更新するEXEあるいはDLLがロードされていれば
> そのロードしているプロセスが誰かなどお構いなしに利用中のダイアログを出してくれます。
>
> プラグインとかだと、そのインストーラから見たら見知らぬプロセスがロードしてるのに
> このアプリが利用中って出ますよ。
まず、うろ覚えだった「GUID」と言っていた部分の訂正から(通じていてくれたらうれしいですｗ)
GUIDと言っていた部分はPackageCodeや、UpgradeCode等を指して使っていました。
そして、以前手にしたIS2010ExpressEditionユーザーガイドでは、
UpgradeCodeは製品ファミリーで統一されている必要がある、と書かれています。
なのでこの部分がひっちゃかめっちゃかの現状では、アップデート(アップグレード)が出来ないと判断しています。

また、形式はMSI形式なのですが、アップデートを配布する際って、
メジャー/マイナー/スモール/パッチのいづれかでの配布になるかと思いますが、
それぞれ(またはどれか？)UpgradeCodeとか関係なくEXE/DLLがロードされているかを判定してくれるのでしょうか？

> 全文引用じゃないから問題ないかとｗ
ありがとうございます！ｗ

引用返信 編集キー/

■72385 / inTopicNo.12)

　Re[7]: 実行中のプロセス取得について

▲▼■

□投稿者/ 渋木宏明 (22回)-(2014/06/06(Fri) 09:45:16)

> A.exeを起動中にUpdater.exeからA.exeが起動しているかどうかを確認できるという事なのでしょうか？

作り込み次第です。

今現在、重複軌道を防止する機構が実装されていないのだとすると、既存物件が起動中かどうかを検出するのは無理ですね。

引用返信 編集キー/

■72390 / inTopicNo.13)

　Re[8]: 実行中のプロセス取得について

▲▼■

□投稿者/ nobb (36回)-(2014/06/06(Fri) 10:54:46)

■No72385 (渋木宏明さん) に返信
ご回答ありがとうございます。

> 作り込み次第です。
なんと！！知りませんでした。自身の多重起動防止にしか使えないものだとばっかり。。。

> 今現在、重複軌道を防止する機構が実装されていないのだとすると、既存物件が起動中かどうかを検出するのは無理ですね。
はい。そうですよね。実装されていないものもあるので、こちらの方法は諦めます。

引用返信 編集キー/

■72391 / inTopicNo.14)

　Re[7]: 実行中のプロセス取得について

▲▼■

□投稿者/ とっちゃん (225回)-(2014/06/06(Fri) 10:56:04)

■No72384 (nobb さん) に返信
>>ISを使ってということですが、形式は何でしょう？
>>どの形式にせよ、一度試してみて本当に自前処理の必要があるかを確認してみることをお勧めします。
> 形式は基本MSIです。
> InstallScript形式は使っていません。
> ちなみに使用しているISのバージョンはIS2011Proです。
>
MSI形式なら、特に問題はないかと。

>
>>インストーラエンジンから検討しなおすかを考えればいいと思います。
> エンジンからということは、そもそもMSIから見直すという事ですか？
> WindowsのインストーラーはMSIのみだと勝手思っていますが、他のエンジンもあるのでしょうか？
>
えっと。。。引用の手前部分から、InstallScript 形式の話を書いていますよ？

もっとも、MSIだから絶対それじゃなきゃだめか？というわけではありませんけど。
＃今のところMSIを代替できそうなデスクトップアプリ向けのインストーラエンジンはないですけどねｗ

>
>>ちなみに、MSI形式で作っている場合ですが、自身が更新するEXEあるいはDLLがロードされていれば
>>そのロードしているプロセスが誰かなどお構いなしに利用中のダイアログを出してくれます。
>>
>>プラグインとかだと、そのインストーラから見たら見知らぬプロセスがロードしてるのに
>>このアプリが利用中って出ますよ。
> まず、うろ覚えだった「GUID」と言っていた部分の訂正から(通じていてくれたらうれしいですｗ)
> GUIDと言っていた部分はPackageCodeや、UpgradeCode等を指して使っていました。
> そして、以前手にしたIS2010ExpressEditionユーザーガイドでは、
> UpgradeCodeは製品ファミリーで統一されている必要がある、と書かれています。
> なのでこの部分がひっちゃかめっちゃかの現状では、アップデート(アップグレード)が出来ないと判断しています。
>
PackageCode は、MSIごとに与える一意識別子になるので、個体判定用に使います。
通常、ビルドするたびに変更され、最小のMSPを作る場合を除いて覚えてなくてもあまり大きな問題はありません。
ただし、リリースしたMSIはちゃんと保持しておかないといろいろ面倒になります。

UpgradeCode は、製品(いわゆるプロダクトのほうです)のVer.1とVer.2はつながっているというように管理する部分ですが
こちらは原則として、Ver.1->Ver.2で自動的に上書きインストールさせたいという場合に活用します。

こちらも、必ず同じじゃなきゃダメというわけではありません。

> また、形式はMSI形式なのですが、アップデートを配布する際って、
> メジャー/マイナー/スモール/パッチのいづれかでの配布になるかと思いますが、
> それぞれ(またはどれか？)UpgradeCodeとか関係なくEXE/DLLがロードされているかを判定してくれるのでしょうか？
>
自分がインストールするファイルが既に存在し、それを更新する必要があれば、そのComponetIdなどがまったく違っていても
自動的にピックアップします。

なので、気にしなくて問題ありません。というか、見ず知らずの製品でもmsvcr120.dllのように自分も相手も
使っているものを更新というような場合は、検出してくれますよ。

一応。。。検出対象となるプロセスは、
・可視ウィンドウを持つプロセスである
という制限事項があります。

これがあれば、エクスプローラであろうが、Officeであろうが、IEであろうが何でも引っかかります。

引用返信 編集キー/

■72392 / inTopicNo.15)

　Re[9]: 実行中のプロセス取得について

▲▼■

□投稿者/ とっちゃん (226回)-(2014/06/06(Fri) 11:12:28)

■No72390 (nobb さん) に返信
> ■No72385 (渋木宏明さん) に返信
> ご回答ありがとうございます。
>
>>作り込み次第です。
> なんと！！知りませんでした。自身の多重起動防止にしか使えないものだとばっかり。。。
>
ついでにフォロー。

多重起動防止は、C/C++ だと、多くの場合 Mutexなどの名前付き同期オブジェクトを使っていると思います(実装次第ですけどねｗ)。
名前付き同期オブジェクトを利用している場合は、名前と同期オブジェクトの種類さえわかれば
存在チェックができるので別アプリからでも動作状態を把握することは可能です。

自分自身とは言いますが、2つ目に起動したアプリの動作は
「この名前を持つ同期オブジェクトがあったら起動しない」
となっていることが多いので、単純な名前を付けると、名前が重複します。
重複してると、見知らぬ他者が原因で自分が起動しないという状態になります。

この重複起動防止もシステムレベルでフォローがあると融通聞いていいんですけどねぇ。。。ｗ
＃画面を出すとかアクティベートするとか。。。ｗ

引用返信 編集キー/

■72393 / inTopicNo.16)

　Re[8]: 実行中のプロセス取得について

▲▼■

□投稿者/ nobb (37回)-(2014/06/06(Fri) 16:22:12)

■No72391 (とっちゃんさん) に返信

> えっと。。。引用の手前部分から、InstallScript 形式の話を書いていますよ？
すみません。。読み違えていたようです。。

どうやら、私の認識が大きくずれていそうなので確認させてください。
「可視ウィンドウを持つプロセス」(←普通に言う、ダイアログとかウィンドウでいいんですよね？)であれば、
UpgradeCodeや、ComponentId等々を気にせずとも、インストールされるEXEが実行中の場合は、
自動的に判定(または何かしらのメッセージの表示？？)を行ってくれる。

という事で大丈夫でしょうか？？
以前(かなり前)、アップデートの実験をしている時に別製品としてインストールされたような記憶があったので・・・
(もしかしたら製品名のスペース(半/全)とかが違ってた・・・？)

#インストーラーは難しい・・・

引用返信 編集キー/

■72394 / inTopicNo.17)

　Re[9]: 実行中のプロセス取得について

▲▼■

□投稿者/ とっちゃん (227回)-(2014/06/06(Fri) 17:42:25)

■No72393 (nobb さん) に返信
> どうやら、私の認識が大きくずれていそうなので確認させてください。
> 「可視ウィンドウを持つプロセス」(←普通に言う、ダイアログとかウィンドウでいいんですよね？)であれば、
> UpgradeCodeや、ComponentId等々を気にせずとも、インストールされるEXEが実行中の場合は、
> 自動的に判定(または何かしらのメッセージの表示？？)を行ってくれる。
>
> という事で大丈夫でしょうか？？

「操作(更新あるいは削除)の必要があり、そのためにプログラムを終了させる必要がある場合」
であれば、上記のとおりとなります。

この時重要なのは、操作対象ファイルが利用中か？であり、そのファイルを利用しているのが誰か？は
特定しますが、誰がインストールしたものか？とかは考慮されません。

極端な例を挙げておきますね。
msvcr120.dll とか使っていると思います。
これらは、自分だけではなくほかの製品でも使っていますよね？
VS2013 だけでいうと、無印、Update1 の2種類のランタイムが存在します(Update2はランタイムは更新されていません)。

これを、マージモジュールで自身の製品のインストーラに組み込んでいれば、更新するインストーラはもちろん
自分が作ったものとなりますし、このファイルを管理するインストーラは自分の作ったものとなります。

ですが、msvcr120.dll は自分だけじゃなく、VS2013を使って製品開発しているすべてのベンダーさんが配布する可能性がある
ファイルです。
その中には、初期版のままのオンラインソフトとかもあるかもしれませんし、開発が終了した業務アプリとかで
半年とか一年とか放置されたままの製品かもしれません。

こういったものでも、稼働はしていますので、自分の製品と関係ないからと常駐ライクに動かしていれば当然引っかかります。

そういう場合でも問題なく表示してくれるのが利用中のアプリを表示する仕組み(MSIのFilesInUseダイアログの出る仕組み)
となっています。

詳しくは。。。と思ったけど、どこを案内すればいいかわからないやｗ
ということでトップを張っときます。
http://msdn.microsoft.com/en-us/library/cc185688.aspx

その昔、Windows Installer の開発チームのメンバーは、聖書を読むように毎日30分でいいからリファレンスを眺めろ
と言っていたくらい、膨大なリファレンスですがｗ

> 以前(かなり前)、アップデートの実験をしている時に別製品としてインストールされたような記憶があったので・・・
> (もしかしたら製品名のスペース(半/全)とかが違ってた・・・？)
>
こっちは、全然違う話です。
PackageCode, ProductCode, UpgradeCode は、製品管理用の識別子でこちらはインストールする製品を
プログラム的に識別するための存在です。
PackageCodeは、msi ごとにユニークな存在になるため、理論的には特定のPackageCode をもつ
msiファイルはこの世に1つだけしか存在しないものとなります(バイナリ的な意味で)。

ProductCode は、製品そのものの識別子で、特定の製品のメジャーバージョンごとに一つというのが一般的です。
(アップデート手段によるので必ず同じとは限らない)。

UpgradeCodeは、同じ識別子を持つものは原則として上書きインストールされる(製品グループ的なもの)として
位置づけられているものです。

これらはそれなりに指針があり、こうすべきであるとかこう管理すると楽というのは存在しますが
ぶっちゃけ何の管理もされていなくて。。。なんていう状況でもほとんどの場合困ったりしません。
(管理してなくても、ビルド可能な状況さえ残っていれば、情報が取れるため)。

> #インストーラーは難しい・・・
OSが提供するテクノロジでは、一番危険な仕組みですからね。作る側にとってやさしい要素は少ないと思いますよ。
しかも、SDKで書かれている内容と今の潮流(昨今のインストーラに求められるエクスペリエンス)はだいぶ違っています。

あと、多くの開発者が忘れていることなんですが、インストーラはその製品で一番最初にユーザーが触れるアプリケーションである
ということも忘れてはならない大事な部分です。

引用返信 編集キー/

■72397 / inTopicNo.18)

　Re[10]: 実行中のプロセス取得について

▲▼■

□投稿者/ nobb (38回)-(2014/06/06(Fri) 18:18:57)

■No72394 (とっちゃんさん) に返信
細かくお教え頂きありがとうございます。
ですが、FilenInUseをキーワードに調べてみると、付け焼刃で行える程甘くなさそうなので
一旦問題の棚上げをしたいと思います。

なんだか逃げるような事を言って本当に申し訳ありませんが、一朝一夕で出来るようなものでもないと思いますので。。。

いづれこの問題にぶち当たる事は分かっていますので、その時に本腰を入れたいと思います。
#恐らくその際にはまたお世話になるかと思いますが、よろしくお願い致します・・・

アップデートに関しては、オレオレアップデーターで対応したいと思います。
本当にありがとうございました。

解決済み

引用返信 編集キー/

■72403 / inTopicNo.19)

　Re[11]: 実行中のプロセス取得について

▲▼■

□投稿者/ とっちゃん (228回)-(2014/06/06(Fri) 20:41:16)

■No72397 (nobb さん) に返信
> ■No72394 (とっちゃんさん) に返信
> 細かくお教え頂きありがとうございます。
> ですが、FilenInUseをキーワードに調べてみると、付け焼刃で行える程甘くなさそうなので
> 一旦問題の棚上げをしたいと思います。
>
解決ついててもう見てないかもですが、FilesInUse の面倒な部分は、こういう風に作りましょうとか
こういう動きで自分で出せますという部分かな？
これらは、InstallShield を使っている場合原則何一つ考慮しなくていい部分です。

ダイアログは最初から用意されていますし(デザインが気に入らないので修正するくらい＜いじる場合)
こういう動きで出せますの部分は、これまで出ていたシステムがやってくれている部分なので
自前でやる必要そのものがありません。

そもそも、MSIを作ったことがある人でも、このダイアログの存在自体知らないという人もたくさんいるはずです。
それくらい一般的じゃない話題でもあります。

> なんだか逃げるような事を言って本当に申し訳ありませんが、一朝一夕で出来るようなものでもないと思いますので。。。
>
おそらく、一朝一夕でできるような。。。と感じた部分は、今まさにつくろうとしているリストアップ処理だとか
ダイアログに表示させる方法だとかの部分ではありませんか？

この部分は、基本的にシステム(WindowsInstaller)がやってくれる部分で、自分で実装する必要のある部分ではありません。

＃あえて末尾は切っておきます

解決済み

引用返信 編集キー/

■72419 / inTopicNo.20)

　Re[12]: 実行中のプロセス取得について

▲　■

□投稿者/ nobb (39回)-(2014/06/09(Mon) 09:35:17)

2014/06/09(Mon) 09:36:40 編集(投稿者)

■No72403 (とっちゃんさん) に返信
お返事遅くなりました。
> これらは、InstallShield を使っている場合原則何一つ考慮しなくていい部分です。
たしかに、作成されたMSI(アップデート用ではないもの)をOrcaで覗いてみたらFilesInUseに関するものが色々ありました。
(それがどう作用しているかまでは把握していません)

一応私が「一朝一夕では...」と判断した理由ですが、
・まず、FilesInUseというものがどういう方法で動き、どうやって表示され、どういう処理が可能か分からない(それは考えなくてもいいのかな・・・？)
・ISでそれが動く為に必要な何か(設定？)があるのか
・(信じていない訳ではないですが)本当にUpgradeCodeや、ComponentId等々を気にせずとも作れるものなのか(を自分で確認していない)
・アップグレードを作った経験がほぼなく、その辺りの知識が乏しすぎる
(・乏しいが故の不安)
・さらっと、ちょびっと調べてみる(ぐぐってみる)と英語情報のみ見つかり、なおかつInstallScript or FilesInUseを抑止したい旨の物が多い

といった理由です
そして、それらをオレオレで実装してしまう方法(起動してますよ！終了させてくださいね！で終了という処理の予定)と天秤にかけた結果です。
いずれの理由にしても「調べろ！そして学べ！！」と言われたら何も言い返す事ができません。

表題の疑問に関しては不要な事だと思い書いていませんでしたが、EXEのアップデート以外にも必要な処理があり、
それはIS(Windows Installerエンジン)では出来ない部分なので、1本のEXEで完了させたいという目的もありました。
#おそらく、きちんとアップデーターを作れば、それをEXE側から起動させればいいだけだとは思いますが。。。

解決済み

引用返信 編集キー/

次の20件＞
トピック内ページ移動 / << 0 | 1 >>

- Child Tree -