2

シェルといくつかのモジュールで構成される Windows Mobile アプリケーションがあります。各モジュールには、インストール用の CAB ファイルを生成するための独自のセットアップ プロジェクトがあり、ベース アプリケーションとして機能するシェル用のプロジェクトもあります。私が抱えている問題は、モジュールのソリューションを開くたびに (各モジュールには、必要に応じて他のプロジェクトを参照する独自のソリューションがあります)、Visual Studio はセットアップ プロジェクトの依存関係を更新し、実際には全体を壊します。セットアップ プロジェクト。

これに関連して私が抱えている大きな問題が 2 つあります。1 つ目は、セットアップ CAB が複数の DLL の 2 つのバージョンを取り込んでいるということです。1 つは Compact Framework からのもので、もう 1 つは「通常の」DLL です。これにより、CAB のサイズが急激に増加し、同じ名前のファイルが 2 つあるため、警告が発生します。

私が抱えている 2 番目の問題は、各モジュールのセットアップ cab にはモジュール DLL のみを含める必要があり、依存関係を含める必要がないことです (それらはすべてシェル CAB の一部であるため)。ただし、ソリューションを開くたびに、CAB を構築する前にすべての依存関係を手動で削除する必要があります。

また、これらのプロジェクトは Team Foundation Server にチェックインされていますが、チェックアウトされずに何らかの方法で変更されていることにも注意してください。

Windows Mobile 5.1-6.5 用の .NET 3.5 Framework に対して開発している Visual Studio 2008 を実行しています。

リリースを行うたびに依存関係を作り直すのは非常に時間がかかるため、この問題についての洞察をいただければ幸いです。

4

1 に答える 1

2

スマート デバイス CAB プロジェクトは忌まわしいものです。最も単純な展開でのみ機能します (それでも制限があります)。すべてのインストールで最終的に行った解決策は、INF ファイルを手動でロールし (現在の CAB プロジェクトが作成するベースライン INF ファイルを使用できます)、バッチ ファイル/コマンド ラインから直接 CABWIZ を呼び出して、インストール CAB を生成することです。面倒に思えますが、実際にはそうではなく、MSBUILD による自動化にも適しているため、展開パッケージのビルドは簡単に自動化できます。

于 2012-12-12T23:28:45.833 に答える