我为我的应用程序提供了一个名为MainWindow.vs2015.sln的解决方案。它有近100个项目，并且可以在Visual Studio 2015中完美构建。当我使用devenv从命令行构建解决方案时，它也可以完美运行，并且没有错误。
但是，当我从命令行构建，然后打开Visual Studio 2015并再次构建时，期望几乎是瞬时构建，就像我已经从命令行构建的那样，它将重新构建整个过程，而我在那坐了将近30分钟，等待一切重新建造。
devenv命令和Visual Studio内部版本之间是否存在某种区别？
P.S我也有MSBuild和devenv，并且有相同的问题。
devenv MainWindow.vs2015.sln /Build "Debug ALL"
答案 0 :(得分：0)
您的项目类型是什么？ VB.net，C＃还是C ++？
对于 for (i = 9; i > 0; i--)
{
printf("%d\n", i);
}
个项目：
如果我们在命令行中创建一个新的VS2015 C＃项目，请以.net组合的形式进行构建。之后，在IDE中打开项目并进行构建时，它将显示Up-To-Date，并且由于没有任何更改，因此将不再进行编译和构建。
因此，如果您在C＃项目中遇到Debug+x64问题，请在VS中将Build Output的详细程度设置为build twice或更高，以查看有关构建过程的详细信息。
之后，当您再次遇到此问题时，请尝试阅读日志的第一部分，以了解VS重新构建它的原因！检查是否缺少某些文件或将其设置为“像this一样的“始终复制”。
对于Detailed个项目：
如果您在其中包含许多C ++项目的解决方案中。恐怕答案是否定的。我在VS2015 C ++项目中对其进行了测试，并且可以重现相同的问题。我发现如果我们创建一个C ++项目，先在命令行中构建它，然后在VS中构建它。 VS会认为它不是最新的，并尝试再次构建它...
有趣的是，如果我们不通过命令行来构建它，而是在VS中对其进行两次构建，则VS可以识别出它是最新的，并且不会浪费时间来第二次构建它。
因此，我建议您避免在VS中进行构建之前在命令行中进行构建。因为没有对源文件进行实际修改而我们使用两种方式构建项目是没有优势的。另外，由于VS for C ++项目中的最新检查有一些可以改进的地方，因此您可以在DC中张贴一个C++，并且可以从那里的产品团队获得帮助。
另外：在VS IDE中进行构建时，请确保用于在命令行中构建解决方案的Configuration + Platform相同。
希望它会有所帮助：）