MSIインストール時の.NET 4.0アップグレードエラー - XMLに予期しない属性エラーが含まれていません

Question

クライアントマシンにWindowsサービスをインストールするためのMSIがあります。 Windowsサービスは、サーバーのWebサービスを呼び出して操作を実行します。 最初は、MSIとWebサービスの両方が.NET 2.0フレームワークを使用して構築されました。

最後の四半期では、システムを.NET 4.0にアップグレードしました。私たちのWebサービスはまだASP.NET、すなわちasmx（そしてWCFではなく）です。また、私はMSIのインストールの前提条件としてフレームワーク4.0を設定しました。

クライアントは、.NET Framework 2.0を使用していた、と彼のシステムにインストールされているMSIの古いバージョンを持っていた：

私たちのクライアントの一つは、この問題を報告しました。 MSIの.NET Framework 4.0バージョンをインストールしようとしたとき、フレームワーク4.0をインストールするように求められました（前提条件のため）。フレームワークのインストールが完了したら、彼はMSIをインストールしようとしましたが、このエラーが発生しました。誰かが私を解決に導くことができますか？必要に応じて詳細を提供することができます。

EDIT 1：より多くの研究で

、私はそれが私のAppName.installstateファイルで見つかりました。 Uninstallはこのファイルを削除しますが、アップグレードはそれを行いません。ファイルはインストールディレクトリにあります。近くに私はファイルの内容に "http://schemas.xmlsoap.org/soap/envelope/:Envelope"を見ることができます。任意のポインタは非常に高く評価されるだろう。

EDIT 2：

カスタムアクションは、インストールはAppName.installstateファイルおよびカスタムアクションのアンインストールファイルを削除し作成します。私の場合、私はこのファイルに何もしないMSIのアップグレードを行っています。 2.0と4.0（どちらも手動でインストールされている）のinstallstateファイルを比較すると、XML構文、スキーマと内容に大きな違いがあることがわかりました。その理由は、シリアル化エラーです。今、AppName.installstateがアップグレード時に上書きされない理由を知る必要があります。 googleの多くを行っているが、どこにも着陸しない。 MSIインストールログを見ましたが、有用な情報はありません。

Answer 1

ユーレカ!!!!

私の問題を解決しました。 MSIは、インストール時に使用する情報を格納する MSIインストール時にXMLファイルを生成する（application_name.installstate）、アンインストール、ロールバック：

根本問題の原因。このXMLファイルのフォーマットは、.NET 2.0と.NET 4.0、すなわちVS2005とVS2010を使用して開発されたMSIとは全く異なります。 4。0 frmaeworkがOld Frameworkバージョン（2.0）で生成されたファイルを理解できないため、「Installstateファイルのタイプをシリアル化できません」というエラーが表示されます。このため、オンラインで利用可能なドキュメントはありませんが 、私は私が試し>http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/bedbb8bd-dad5-4bcb-a87a-ac69386669b4/

ソリューションを見つけ、この議論がある（私はそれを動作アラウンド呼ぶだろう）： を新しいバージョンのインストール時に、私は明示的に古いを交換しています新しい形式のXMLファイル（4.0）。つまり、私のパッケージにapplication_Name.installstateファイル（新しいバージョンで生成）が含まれていたため、アップグレード中に古いファイルを上書きしました。 MSIがエラーなくインストールされ、正常に実行されています。

誰かが問題と解決の両方について詳細を必要とする場合は、ここに返信してください。

Answer 2

このエラーメッセージは、1001エラーメッセージごとにインストーラとは関係ありません。問題は完全にあなたのサービスの中にあります。

サービスのOnStartメソッドは、バックグラウンドプロセスをスピンアップし、成功をサービスコントロールマネージャーにできるだけ早く返すことを何もしてはいけません。 SCMは、サービスを開始する際にエラーが発生したと想定する前に、SCMが長時間待機するだけなので、そのクリティカルパスに長い実行コードは存在しないはずです。

サービスをリファクタリングして別のスレッドでジョブを実行すると、インストールが正常にインストールされます。そこから、DeSerializationプロセスで起こっていることの本当の問題に集中できます。