マイクロソフトは8年以上にわたって.Netを推進しています。ソフトウェアのバージョン管理：Windowsインストーラと.Netバージョンの相違点
.Netアセンブリは、major.minor [.build [.revision]]のように4バージョン付けを使用してバージョン管理されています。 Ref here
Windowsインストーラーは、まだmajor.minor.buildのような3バージョン付けを提案します。 Ref here
2つのシステムでバージョン管理の違いがあります。 .Netアセンブリバージョンをインストーラにマップするのは簡単ではありません。 .NetアプリケーションのインストールにWindowsインストーラを使用するのは非常に複雑です。特に、リビジョンの変更に対して製品のアップグレードを実装したい場合は特にそうです。
このような状況を克服するにはどうすればよいですか？リビジョンの変更が最小限であっても、製品をアップグレードしたいと考えています。
なぜ.NETアセンブリのバージョンを製品バージョンに直接マッピングしますか？あなたは本当にあなたの製品に1つだけのアセンブリを持っていますか？
私が見たほとんどの製品構成管理プロセスでは、通常、その製品バージョンに含まれるバイナリ、構成ファイル、ドキュメントのバージョンを示すマニフェスト（別名部品表）を持つ製品バージョンを追跡します。これにより、開発プロセスがリリースプロセスから切り離されます。これは、商用製品だけでなく、良いことです。
私たちは複数のアセンブリを持っていますが、私たちは、コードベースで行うわずかな変更のためにクライアントを最新バージョンにアップグレードしたいと考えています。したがって、アセンブリバージョンの最後の部分としてSVNリビジョン番号を含めます。 いくつかの製品番号は、アセンブリのバージョンと同じにしておきたいものです。それは間違っていますか？ – NileshChauhan
識別スキーマは安定しており、予測可能でなければなりません。アップグレードポリシーは将来変更される可能性があります。あなたのアセンブリバージョンIDにリビジョンを含めても問題ありませんが、あなたの*製品*はあなたのアセンブリの合計以上のものです。お客様の製品は、お客様に出荷することを決定したものです。出荷の決定はビルドの決定とは別です。常に変化の計画を立てる。 私のアドバイス：別の製品バージョンIDを提供し、顧客に見えるようにする（インストーラ、ヘルプ>バージョン情報）、BoMのリンク製品バージョンをアセンブリバージョン（ドキュメントリビジョン＆c）に提供する。 –
.NETで使用されるバージョンとWindowsインストーラは、異なる懸案事項に対処しています。 .NETでは、アセンブリバージョンは、ロードするアセンブリのバージョンを決定するためにローダーによって使用されます。同じアセンブリの複数のバージョンをGACに展開し、それらを並べて使用できることを覚えておいてください。ロードするアセンブリの正確なバージョンを指定するポリシーを設定することもできます。私はGACでアセンブリAの異なるバージョンを持つことができ、バージョン1を使用するアプリケーション1とバージョン2を使用するアプリケーション2を持っています.Windowsインストーラについてそれほどよく分かりませんが、バージョンと製品のGUIDを使用してどのバージョンのアプリケーションがインストールされているかを確認して、インストールしているアプリケーションがインストール済みのものより新しいかどうかを判断し、ユーザーに警告したりアンインストールしたり、ユーザーに選択させたりすることができます。
これは克服するものではありません。周囲を受け入れて設計することは設計上の制限です。はい、戸惑いがちですが、近い将来変わる可能性のあるものはありません。 Windows Installer ProductVersionsは3つの部分に基づいています。また、最初の2つの部分は255を超えることはできませんが、3番目の部分は65,535まで可能であることを忘れないでください。
Windowsインストーラは10年以上前から存在していました。しかし、いずれにせよ、私は彼らの典型的な4つのパートのバージョンの唯一の3つの部分を迷惑をサポートすると思う。 –