配置完成后点击保存后，构建该项目查看结果。若能够将源代码更新至Jenkins的工作空间内，则代表配置成功!
四、通过MSBuild编译应用程序 1.安装插件与环境编译.NET应用程序可通过微软提供的MSBuild工具，先安装插件:MSBuild。(注意:Jenkins服务器需安装MSBuild，建议在Jenkins上安装VS开发工具，可以在构建出问题的时候打开VS调试，省去很多不必要的麻烦)。
2.全局配置插件安装完毕后，进入系统管理->全局工具配置(ConfigureTools)找到MSBuild配置选项:
Name：自己起个名字
Path to MSBuild:MSBuild.exe程序的物理路径
注意:此处MSBuild.exe必须与程序所使用freamwork版本相对应，此处我在这就遇到了一个大坑，一开始随便找个一个MSBuild工具，没想到根本编译不了C#6.0的语法。建议直接指向visual studio安装目录内的MSBuild.exe,可以避免很多问题。如VS2017在:Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin路径内。
3.项目配置打开我们之前创建的项目，找到构建选项->增加构建步骤->Build a Visual Studio project or solution using MSBuild
Name:选择全局MSBuild配置的名称
MSBuild Build File:填写我们的要构建的项目.csproj文件，所相对工作的路径。如:/Test.csproj
Command Line Arguments:MSBuild的参数如：/t:Rebuild /P:Configuration=Release /p:VisualStudioVersion=14.0 /p:DeployOnBuild=True;PublishProfile=Test.pubxml
/t:Rebuild 重新生成
/p:Configuration=Release Release 生成模式
/p:VisualStudioVersion=14.0 指定子工具集(VS2015为14.0，2017为15.0)，不设置会报错
/p:DeployOnBuild=True;PublishProfile=Test.pubxml 使用 Test.pubxml 发布文件来发布项目 .pubxml文件可在VS发布时配置，位于Properties文件夹内。
配置完成后，点击构建，查看控制台信息，如能构建成功，则代表我们的配置无误！
4.遇到的问题原以为按照度娘的一系列解决方案能够很顺利的构建，可是在连续失败了几十次之后，才明白远远没有那么简单。期间主要遇到几个问题：
MSBuild版本不对导致构建不了C#6.0的语法
Jenkins 是讲版本库源代码更新到自己的工作空间内，再执行后续的构建工作。我们的程序很不规范，其中引用了许多不属于自己版本库的第三方依赖包，和一些自己开发的公共库，当时这些第三方包和公共库放在我们SVN的另一个版本库里进行管理，因此在构建的时候导致很多程序集找不到引用。
关于问题1:上面已经提过，只需要找到对应版本即可
而问题2:一开始找了很多资料也没有找到解决方案，后来还是从源代码管理上找到了方案。
方案1：
借鉴Nuget的思想，使用Nuget服务器管理我们自己开发的一些公共依赖库。关于Nuget管理依赖的文章在另一篇博客里。
方案2:
就是上面提到的SVN 外部引用，当时也是走投无路，于是疯狂翻译Jenkins的这些英文解释，在翻译到SVN插件的Ignore externals时，找到了这种方案，就是SVN可以设置外部引用，这样在更新版本库的时候就可以把依赖的版本库也更新下来，然后Jenkins SVN插件把这个Ignore externals选项去掉，然后在Additional Credentials选项里填上所依赖版本库的SVN配置，就能够把这些依赖也更新到SVN工作空间内。
以上两个问题解决后，基本没有遇到太难的问题。由此可见我们的源代码管理的科学、规范是多么的重要。
几十次的构建失败，一堆乱七八糟的引用是多么痛的领悟!
五、通过Ftp发布至应用服务器