• 締切済み

VB2008で作成したアプリがインストールできない

最近になってVB2008で作成したアプリをインストールすると”アプリケーションを起動できません。アプリケーションのベンダに問い合わせください”と言うダイアログが表示されます。 詳細を見てみると”----のライセンス認証により例外を発生しました。---ストア メタデータ "DevelopmentProviderUri"が無効です。”とあります。 これはどういうことなのでしょうか? レジストリが壊れたのでしょうか? PCはXP-SP3です。 他のPC(Win7)にはインストールできます。 対処方法がありましたら教えてください。

みんなの回答

回答No.3

ライセンス認証がどのようにデータ管理されているか実際の手法はやはりブラックボックス状態の様でWebでもMSサポートでも分かりませんでした。 エイヤで以下検索を掛けてみたらUpdateか何かからんでいそうな以下の結果が得られました。 ライセンス認証とメタデータの因果関係とか管理方法は分かりませんでしたが以下ご参考まで 5番目の Software Update Services および Windows Server Update Services におけるコンテンツの変更について (2008 年) 当たりが気になります。 MSサポート「ライセンス認証とメタデータ」 http://support.microsoft.com/search/default.aspx?mode=a&query=%E3%83%A9%E3%82%A4%E3%82%BB%E3%83%B3%E3%82%B9%E8%AA%8D%E8%A8%BC%E3%81%A8%E3%83%A1%E3%82%BF%E3%83%87%E3%83%BC%E3%82%BF&spid=global&catalog=LCID%3D1041&res=10 参考まで

回答No.2

>詳細を見てみると”----のライセンス認証により例外を発生しました。---ストア メタデータ "DevelopmentProviderUri"が無効です。”とあります。 NT系はメタデータで管理する手法をとっていて単純にライセンスを管理するメタデータに異常があったと思います。 以前は問題が無かったと言う事でいいのでしょうか? ライセンスであれば、おそらくレジストリーで修正できたら違法コピーを抑えきれないと思いますのでライセンスを取り直すと言うよりは「取り戻す」しかないのではないかと思います。 メタデータはご存知でしょうか?小生も正直分かるような分からないような感じです。 データ管理のためのデータ?? 一例で言えば クラスタ単位の情報の有無をビットマップで管理していて1ビットで1クラスタを管理しています。 HDDエラーチェックはこのデータを元にダブルブッキングを解消したりもしているようです。 同手法のメタファイルならば"DevelopmentProviderUri"に関するメタデータの1ビットこけているだけだと思います。 MSサポートで「メタデータが無効です」で検索すると「Office系のライセンス無効…」がでてきます。 その辺が参考になるかと思います。 小生の前回の回答、的を得ず申し訳ありませんでした。

回答No.1

失礼な表現、記載、誤記等ありましたらご容赦ください。 >最近になってVB2008で作成した…アプリケーションを起動できません。アプリケーションのベンダに問い合わせください… >…詳細を見てみると”----のライセンス認証により例外を発生しました。 >…ストア メタデータ "DevelopmentProviderUri"が無効です。”とあります。 >PCはXP-SP3です。他のPC(Win7)にはインストールできます。 小生、最近はやってませんが、以前Windcows98時代にVB(Ver.6),VC++(Ver.6)等をでプログラムやそのインストーラを作った経験があります。まだ、その時のプログラムはXp上で動いています。 プログラムはXpでは作っていません。 それと、(大型)コンピュータの基礎やMPUの動作程度の知識はあります。 以下、小生の経験と過去に勉強したコンピュータの知識で推定です。 外していたら済みません。 可能性としては纏めれば 1.上位OSでコンパイルした。 2.下位CPUで実行できない形式でコンパイルした そんなところだと思います。 対処は 1.下位OSでソースレベルで移してコンパイルする。 2.下位CPUで実行できるレベルでコンパイルする。 【説明】 そのプログラムはWindows7とWindowsXpどちらで作ったのでしょうか? Windows7ではないでしょうか?違うならばCPUのビット数が違いませんか? ソフトの世界は上位コンパチが常識です。上位とはバージョンや性能です。 バージョンアップでリニューアルした、機能強化された部分は当然下位OS、下位CPUではオペレート出来ません。 もし、Windows7でコンパイルしていたらWindowsXpでは動かないことは十分あり得る話です。 よって、ソースプログラムをXpへ移動してXpでコンパイルからやり直せば、コーディングにXpにスペック的に適合しないステートメントやコマンドが無ければ動くと思います。 当然、Xpでコンパイルしたプログラムは7でも動くと思います。 もう一つは、CPU(中央処理装置)の機械語は本来は同仕様マシーン固有のものなので、コンパイルされたプログラム(機械語)はパソコンでは動いても大型では意味のないデータにすぎません。 同系列のCPUでもアセンブラレベルで64bit命令など存在すると思いますが32bitCPUでは64bit命令は当然扱えません。 CPUの系列やbit数が大事で、Xpでは x86とかx64とかでWindows Updateパッケージが異なっていたと思います。 多分この辺はCPUのビット数やその他の理由で機械語レベルのコードが違うための処理と考えています。 要は同系列のCPUでも32bitや64bitが存在し、32bit命令と64bit命令が存在すると考えられコンパチビリティがあれば32bit命令でコンパイルしなければ当然32bitのCPUで動かないコンパイルになります。 64bitとか対応可能のコンパイルとか32bitコンパイルとか、そういうコンパイル処理機能があるか否かはよく知りませんがあれば64bit処理が当然早いが、32bitCPUでは動かない。 インストーラパッケージも同じことが言えるので考慮してください。 以上

ohyama1492
質問者

お礼

Uncle john様  ご丁寧な回答を頂きありがとうございました。  私の質問の仕方が悪かったと思います。  VB2008はXPのPCにインストールしてソフト開発しています。そのPCでコンパイルし、VB2008Expressの「発行」でインストール・パッケージを作成してそのPCにインストールすると症状が出ます。そのパッケージをWindows7のPCでインストールすると問題ありません。  数週間前には問題なくインストールできていましたし、以前開発した問題なくインストールできていたパッケージをインストールしても同様な症状を起こします。  他のソフトのインストールは問題なくインストールできています。  どうも"DevelopmentProviderUri"絡みの問題のように思います。  "DevelopmentProviderUri"はVBのインストーラーに使われているようです。    フリーのインストールツール(Inno Setup)でVB2008でコンパイルしたものを発行パッケージにしてインストールできました。

関連するQ&A