MSBuildプロジェクトファイルは、ビルドプロセスでNMAKEメイクファイルと同じ目的を果たしますか？ （実質的に同等）
このような概念的な「プロジェクト」を構築する背後にあるマイクロソフトの動機を理解するのは難しいと感じています。 MSBuild.exeとNMAKE.exeをVisual Studio 2015のインストールと共に出荷しますが、どちらも同じ目的を果たしているようです。
それらが両方とも（実用的な意味で）同等であるが異なる形式を使用している場合、両方を記述する方法を学ぶ必要はありません。どちらも独自の目的を持っているなら、私は再考するかもしれません。
以下のテキストは、全体についての私の現在の理論です...しかし、私とは異なり、これらのファイルをカスタマイズした経験を持つ人々がいる可能性があるので、私はこの質問をしました...
MSBuildは、コンパイルのためにVisual Studio環境（.slnファイル）に大きく依存しているユーザー向けに作成されているようです。そして、それについて少し読んだとき、私は自分自身に尋ねました。依存関係のコンパイルは、MSBuildを使用するときに部分的なコンパイルを可能にするさまざまなプロジェクトによって分離できないのですか？そのためには、ソリューションに複数のプロジェクトを作成し、ソリューションを構築して製品全体を構築する必要があります。
ご覧のとおり... MSBuildの理念と、ビルドプロセスでMSBuildが必要な理由を理解しようとしています。現時点では、それが実際にNMAKEに基づいていて、コンパイルしてNMAKEコマンドになっているのではないかと考え始めています。同じビルドプロセスで誰もが両方を必要とする理由がわからないので、それは非常に理にかなっています。
どちらも、複雑なビルドプロセスを制御および自動化するという同じ目的を果たします。ただし、MSBuildはより近代的で、機能が多く、Visual Studioのビルドプロセスにかなり（！）よく統合されますIDE（どちらも実際には同じ "input csprojやslnファイルのようなファイル形式」です。これらのプロジェクトファイルは、適切に構造化された「プロジェクトプロパティ」ダイアログで実際に編集して（少なくとも98％まで）維持できます。nmakeファイルでは、NMakeがこの目的のために設計されています。
IMHO NMakeは、下位互換性のため、プラットフォーム間の互換性が優れているため、Visual Studioに同梱されています。VS IDEの完全に外部にあるビルドプロセスにツールを統合する必要があるタスクに適している場合があるためです。後者もMSBuildで実現できますが、ビルド構成を手動で作成する必要がある場合は、NMakeがIMHOに適していることがよくあります。これは、makeが設計されているためです。
Wikipedia によると、NMakeは1977年に起源を持つUnix makeコマンドのMicrosoftによる実装でした。その歴史のために、メイクファイルを使用するプロジェクトはまだたくさんあります。特にUnix/Linuxの世界では、makeは依然として広く使用されているツールであり、NMakeのようなツールは、そのエコシステムで使用されるmakeツールとの互換性を向上させます。
依存関係のコンパイルを異なるプロジェクトで分離して、MSBuildを使用するときに部分的なコンパイルを可能にすることはできませんか？そのためには、ソリューションに複数のプロジェクトを作成し、ソリューションを構築して製品全体を構築する必要があります。
これは、より大きなプロジェクトの標準的なアプローチであり、驚くべきことではありません。しかし、その抽象化レベルでは、make/NMakeと違いはありません。