首先，我通过观察 Visual Studio 使用其默认的 .*proj 文件编译事物有一个基本假设，如果您连续两次构建相同的解决方案，它会检测到没有任何变化并且似乎在解决方案构建中飞速发展.这是否意味着它知道项目中没有任何更改，并且不必生成新的 DLL 输出？
如果是这样，我有一个问题。假设我有一个包含多个类库的解决方案，并且每个项目中有一个 MSBuild 任务，它通过修改 AssemblyInfo.cs 自动增加构建的版本。事情是（如果我之前的假设是正确的）它每次都会这样做并触发每个类库的新重建。 MSBuild 中是否有可以判断项目是否需要重新编译的目标或属性，如果需要，则跳过我的版本控制步骤？
我问是因为假设我更新了项目 A，而不是解决方案中的项目 B。如果我在解决方案上运行构建，我希望它更新项目 A 的版本，但由于项目 B 没有更改，我想不理会它。
【问题讨论】：
标签： msbuild build-process
发现了一些东西：http://msdn.microsoft.com/en-us/library/ms171483.aspx
MSBuild 可以比较时间戳 具有时间戳的输入文件 输出文件并确定是否 跳过、建造或部分重建一个 目标。在下面的例子中，如果 @(CSFile) 项中的任何文件 集合比 hello.exe 更新 文件，MSBuild 将运行目标； 否则会被跳过：
<Csc Sources="@(CSFile)" OutputAssembly="hello.exe"/> </Target>
...那行得通。但后来我开始思考，如果有人在没有程序集的情况下从源代码控制中提取代码怎么办（我们就是这样做的）？由于它没有可比较的输出，因此无论如何它都会编译并增加版本。我认为复杂性可能会导致我放弃这种方法。
【讨论】：
是否在开发人员框中增加并不重要 - 重要的是您的每日/CI 构建仅在需要时增加。所以，我过去所做的是让一些小的 XML 文件包含下一个内部版本号，并让一个 MSBuild 任务获取这个 xml 文件并创建一个名为 Version.cs 的文件（包含您通常会在AssemblyInfo.cs)。
Version.cs 永远不会检查到您的源控制中 - 它是由构建生成的。
开发人员将同步当前的 XML 文件，构建他们的二进制文件，并获取当前的版本号。持续集成构建也可以做同样的事情。但是每日/官方构建会签出 XML 文件，增加版本信息，然后签入。从那一刻起，版本号已正式更改。
这个主题有多种变化，但总体思路可行。
【讨论】：