0

私は厄介なアンインストール/インストールの問題に取り組んでおり、google-fooを使い果たしたので、誰かが私を正しい方向に向けることができることを期待してここに来ています。

シナリオ:AnthillProを使用して、レガシーASP Webサイト(VS2003でビルド)をWindows Server 2003(x64 SP2)Webサーバーにナイトリービルド/デプロイし、ほとんどの場合、正常に動作します。AnthillProアカウントは、製品コードを使用して前夜の更新パッケージをアンインストールしてから、MSIの名前を使用して新しいパッケージをインストールします。

例:
msiexec /qb /x {89B05BA3-679C-4120-BD6A-339BC3E726FD}
msiexec /qb /i "Update package.msi" PARAMETERVAL=X

これは、QAおよび本番Webサーバーでは問題なく機能しますが、開発サーバーでは常にエラーが発生します。
The installation source for this product is not available. Verify that the source exists and that you can access it.

これに関する最も興味深い詳細は、AnthillProアカウントがインストールしたときに、[プログラムの追加と削除]ウィジェットに更新が表示されないことです。私は数週間前にこの問題を最初に発見し、 ALLUSERSプロパティを手動でMSIに追加して2に設定することで修正したと思いました。これも、Visual Studio 2003ソリュ​​ーションであるため、AllUsersプロパティを設定するだけでは不十分です。インターフェイスを介して。

QAとProdの最新のアップデートを見ることができますが、それはdevボックスで特別なもののようです。結果のMSIに実際にALLUSERSプロパティがあることを確認し、2ではなく1に設定してみました(この説明による)。

MSIはビルドごとに上書きされるため、インストールが実行されているディレクトリに元のMSIが残っていないことは事実ですが、すでに存在するものを再デプロイしようとすると失敗します。

開発Webサーバーにログインして自分でインストールし、UIで[すべてのユーザー]オプションが選択されていることを確認すると、別の自動展開を試みても同じ動作を示します。アップデートがボックスにインストールされていないことを確認し、自動展開を開始すると、成功しますが(アンインストールで何もアンインストールできないという警告を発した後)、「ソースが利用できません」で失敗します。 「その後、別の自動展開を試みるとエラーが発生します。

MSIとMSI自体を含むフォルダーのアクセス許可は、dev、QA、およびProd間で同一であるように見えます。残念ながら、AnthillProが使用しているアカウントのパスワードを持っていません(企業のセキュリティを確保するためです)が、少なくとも、気が向いている場合は、チェックしてくれる人にアクセスできます。この方法を使用して、最新バージョンのアップデートをインストールすると、AnthillProアカウントがそれを認識できることを確認しました。

誰かがこの問題を引き起こしている可能性があるものについて何か考えを持っていますか?

このサイトを多用して数年経ちましたが、ようやく分解して最初の質問を投稿しましたので、このシナリオが混乱したり複雑になったりする場合は、ご安心ください。必要に応じて詳細をお知らせします。

4

2 に答える 2

0

最終的に、Web アプリのすべてのバージョンをアンインストールし、手動でレジストリを調べて、Web アプリの名前、アップグレード コード、および各バージョンのさまざまな製品コードへの参照をすべて削除することで、これを修正しました。

ストレスがたまりましたが、やっと解決しました。これをここに残しておくと、レジストリは常に敵であることを将来誰かに思い出させることができます.

于 2012-05-17T17:17:08.717 に答える