我在小型.net商店工作，目前我们使用visual studio IDE构建所有解决方案。我们希望能够完全控制我们用于构建，测试，部署的MSBuild脚本 - 利用MSBuild社区任务等。
我想我的问题是： Visual Studio开发体验会有什么不同？
如果我们正在创建自己的MSBuild .proj文件，这是否意味着我们不再拥有.csproj文件？项目现在如何看待VS？
我错过了一些非常明显的东西吗？
更新 感谢大家花时间回应。 我知道一些构建工具：CruiseControl，TeamCity等，以及vs项目（.csproj等）只是MSBuild文件。 我想要处理的是那些决定编写自己的脚本和自己的.proj文件的人。他们是否使用VS .csproj文件作为“容器”来保存IDE中的代码文件？他们如何触发自己的开发者构建？他们只是从命令行启动MSBuild吗？在工具栏上有一个按钮可以有效地做同样的事情吗？
总结 - 是的，您确实可以通过调用.sln文件或.csproj文件来使用其他工具来驱动您的构建，但还有另一种方法 - 这是如何工作的？
答案 0 :(得分：6)
我们使用msbuild进行自动构建，您只需将msbuild指向解决方案文件而不做任何更改。
另外，为了澄清，我们还使用了一个自动构建服务器（带有.Net插件的Hudson），它使用msbuild来自动化该过程。
答案 1 :(得分：2)
您应该查看CruiseControl.NET而不是滚动自己的自动构建和CI流程。它变得更容易，它可以做更多的事情，比如运行直到测试或代码覆盖工具或其他任何东西作为构建过程的一部分。
答案 2 :(得分：2)
Visual Studio开发经验会有什么不同？
通常没什么。事实上，如果你做得对，那应该是透明的;您的IDE不应该关心您使用的构建管理器。这就是CruiseControl.NET和Hudson这样的解决方案很好的原因。
如果我们正在创建自己的MSBuild .proj文件，这是否意味着我们不再拥有.csproj文件？项目现在如何看待VS？
您的解决方案结构保持不变。在Visual Studio中，解决方案和项目作为项目组织/打包指南和IDE的便利性具有双重功能。您的构建管理器将对此进行内省，以了解需要构建的内容。
答案 3 :(得分：2)
有几种可用的自动化和连续构建工具，它们构建在MSBuild之上。您的C＃项目文件已经 ARE MSBuild文件 - 所以实际上，自从VS2005以来，您一直在本地工作站上使用MSBuild来创建您的构建 - 您可能根本就不知道它： - ）< / p>
除了CruiseControl.NET（JP提到）这绝对值得一看，我还推荐了两个产品：
FinalBuilder Server这对于绝大多数开发人员来说似乎几乎不为人知（但它绝对值得更多关注！优秀的工具）。如果您需要，它们还有一个独立的桌面版FinalBuilder。它不是免费的 - 但是一个用户100美元（5美元450美元），这真的不是一笔巨额开支
TeamCity - 也因其在.NET世界中的Resharper产品而闻名 - 为最多20个用户/构建计划的团队提供免费的Pro版本，以及更昂贵的企业版，如果你长大了:-)
与CruiseControl.NET相比，两者都提供了友好，友好的GUI，既可以配置构建，也可以监控它们。
正如我所提到的 - 两者都建立在现有项目和解决方案文件结构之上，所以根本不需要改变任何内容。
持续集成真的不会出错！我不能没有立即建立反馈......
马克
答案 4 :(得分：1)
我们在工作中使用TeamCity;我们从CruiseControl.NET开始，但是当另一位开发人员向我指出我将永远维护cc build时，我们会切换。 ;）说真的，TeamCity非常容易学习和使用。
当我第一次听说持续整合时，我问过类似的问题。您是否必须手动重写（和维护）所有解决方案和项目？你需要学习MSBuild命令吗？简短的回答是否。正如Harvey先生所说，您可以在VS创建的解决方案或项目文件上调用MSBuild，它将为您构建它。 TeamCity将自动处理此问题。
如果您想要更多灵活性，我建议NAnt。我曾经使用手工编码MSBuild脚本，这是一种令人沮丧的练习。 NAnt有一个更清晰的语法，（对我来说）更容易使用和阅读。我们使用NAnt作为花哨的东西，并且（再次）在我们想要构建项目或解决方案时从NAnt调用MSBuild。 TeamCity支持NAnt。
总结一下，对于我们来说，Visual Studio中没有任何改变。我们仍以同样的方式创建和维护我们的项目和解决方案。当我们将它们检入源代码控制（TFS）时，TeamCity会自动选择它，构建解决方案并运行我们的（NUnit）测试。我们还设置了一键式部署构建（在TeamCity中使用NAnt）。
答案 5 :(得分：1)
感谢大家的回复，但经过一些研究，我发现了一些关于如何做到这一点的想法：
所以我发现的是： 来自Scott Hanselman的这篇较早的博客文章code organisation。在这里他使用的是Nant而不是MSBuild，但底层的概念是通过.bat批处理文件执行你想要的nant / msbuild项目。
“在这个源目录中，我们有类似build.bat和buildpatch.bat的东西。目标是人们可以从源代码控制中获取内容并键入BUILD并在某个地方有用。能够可靠地非常安慰并简单地构建一个完整的系统。“
从中我可以看出他（显然）仍在使用.sln和.csproj将他的文件保存在一起用于VS - 如果需要可以通过VS构建 - 但实际上是通过Nant .build文件进行构建，通过.BAT。
这篇文章（也来自Scott Hanselman）展示了如何从Visual Studio中execute external tools（如MSBuild或.bat文件）。所以我创建了一个类似于：
的build.bat文件@echo off
echo Building %1 solution from build.bat
echo Directory: %~p1
C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe %~f1 %2
（我从here获得了funky~p和~f参数修饰符;％~f1将MySolution.sln扩展为sln的完全限定路径;） - ）
然后我设置了Visual Studio“外部工具”对话框，以便： - 命令是“build.bat” - 参数是“$（SolutionFileName）/ v：m” - 初始目录是“＆amp;（SolutionDir）”
然后我在工具栏中添加了一个按钮来执行它。 我可以进一步映射F5键来运行它，而不是标准的Visual Studio构建。
无论如何，这些只是一些想法（诚然来自别人的大脑！）但它让我更深入地了解构建以及如何完成它们。有一些限制（例如错误不会出现在错误列表窗口中），但我确信如果需要可以解决这个问题。
我要试一试，看看我能在MSBuild上独自完成什么，然后尝试连接到Hudson，看看有什么厨师！ ： - ）
顺便说一句，如果有人还在阅读这一点，并且对我在自己的答案中提出的内容是好/坏/正确/错误/矫枉过正/过时/有缺陷/无论如何都有意见，请感受你可以自由地提出意见。
好的， 皮特。