1

私は、技術の基本的な知識と Web ベースの製品から来ている、やや複雑な 4 年間のWPFプロジェクトの新人です。WPF

製品は常に 2 つのクライアント向けにリリースされており、ブランドが異なります。以下にいくつかの相違点を示します。

1. Images in the resources folder.
2. Change (name, target, icon) in the installer project.
3. Installer general properties > change {AddRemoveProgramsIcon , Product Name , Title}/
4. Installer UpgradeCode.
5. Update msi installer name.
6. Remove dlls from references.
7. Config. files: CommonAssemblyInfo.cs> change AssemblyTitle, AssemblyProduct
8. Search and replace in many String resources files.

では、これらの手動の手順のすべてまたはほとんどを自動的に実行する実行可能な方法はありますか? ビルド前およびビルド後のアクションに関する記事をいくつか見つけましたが、これまで試したことはありません。それが適切な解決策である場合、カバーされるポイントはいくつですか?

ありがとうございました。

4

1 に答える 1

1

これは基本的に、離散数学/集合論の演習です。Windows インストーラーの世界では、マージ モジュールを作成して、コンポーネントのコレクションをカプセル化できます。最も単純な例では、3 つのマージ モジュールが必要になります。

1) クライアント A ファイル マージ モジュール

2) クライアント B ファイル マージ モジュール

3) 共通ファイル マージ モジュール

インストールするオプション機能が複数ある場合は、共通ファイルをさらに分割できます。クライアント A のファイルとクライアント B のファイルに、これらのオプション機能の固有の構成データが含まれている場合は、これらのファイルを分割することもできます。

また、独自のブランドとアイコンを使用して一意の EXE 名 ( ClientA.exe および ClientB.exe ) を作成し、それらをそれぞれのマージ モジュールで使用するときに、一意のショートカット情報を提供できるようにすることをお勧めします。これらの EXE は、共通の DLL のコア機能を備えた非常に薄いベニアにします (DRY: Don't Repeat Yourself)。

最後に、非常に薄いベニアでもある 2 つの MSI プロジェクトを作成します。ProductName、UpgradeCode、Feature Treee、Dialog UI のみが含まれています。すべてのファイルがマージ モジュールを介して参照されていないため、ファイルはありません。

Windows Installer XML や InstallShield などのツールを使用して UI を生成している場合、単一のプロジェクトから両方の MSI を構築して何も繰り返さないようにする方法があります。ただし、これは非常に高度なオーサリングに入り、高度な抽象化を掘り下げる前に、「基本的な」MSI オーサリングをしっかりと理解する必要があります。また、WiX は「フラグメント」をサポートし、InstallShield は「開発者インストール マニフェスト」をサポートしますが、厳密に言えば、Windows インストーラーのみのマージ モジュールはすべてのツールでサポートされます。

于 2014-01-14T14:47:39.400 に答える