shinetechcq_vsts

SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified

软件回归测试及其实践

builds out of the box

Team Foundation Server

Team Foundation Server - Build Automation

MSBuild Reference

Now this software is really neat. It is based on Microsoft's new MSBuild technology, and rocks. When you get the Team Foundation Server disk you have the ability to install a Team Foundation Build Server, which has the sole purpose of allowing you to specify it as the destination server when issuing a "Build > Build Team Project {your project}" from the VS IDE. When you create a "Build > New Team Build Type" from within the VS IDE, you get to specify tests that you want to run during the build. Once you have created the New Team Build Type, you can effectively access the MS BUILD XML File it creates under the hood, to edit/customise as much as you like. How? Simple, go to "View > Other Windows > Source Control Explorer" then Exand the "TeamBuildTypes" folder then access your new {your Build Type folder}, then double click the *.proj file. Then edit away! I need to do some customisation work in this file and set-up a nightly build, so will blog again once I know more! here's a decent MSDN link : http://msdn2.microsoft.com/en-us/library/ms181709(en-US,VS.80).aspx

I was new to MsBuild when I found the article but I did struggle through learning it in short order and feel better for the experience now. 1. You can call the smoke test (SmokeTest.proj) which exercises the features by running from the Visual Studio command line: "MsBuild SmokeTest.proj"... or if you just want to debug "MsBuild SmokeTest.proj /verbosity:diag /property:DebugProj=true". I would strongly suggest creating your own SmokeTest.proj file and getting it working over your own stuff first. Try simply running MsBuild over your own SmokeTest.proj file until you have tuned the settings right  and understand the basics, then deploy it. I also found that our own SmokeTest.proj that we built was really useful for the developers because they could run it from the command line (in the background) to run all tests, freeing up their VS IDE to continue programming. 2. I would ignore the elements in the article that discuss the code coverage or the clean up. I did not use them as the MsTest command can generate code coverage without issue. 3. We integrated it into our Nightly Build by putting (something like) the following code into our build proj file that runs every night:    <!-- Property that indicates where the Bugslayer dll resides -->   <PropertyGroup Condition ="'$(BUGSLAYERBUILDTASKSDIR)' == ''">      <BUGSLAYERBUILDTASKSDIR>c:\Bugslayer\bin\debug</BUGSLAYERBUILDTASKSDIR>   </PropertyGroup>    <PropertyGroup>      <UnitTestNamingConvention>*UnitTests.dll</UnitTestNamingConvention>      <!-- The StartDirectory property is very important that it is formatted correctly and points to a             real location. It is a primary reason why RunTests.Targets fails -->      <StartDirectory>$(BuildDirectoryPath)\$(TeamProject)\Nightly Build\Binaries\Win32\Debug\</StartDirectory>   </PropertyGroup>   <PropertyGroup>      <AdditionalExcludeDirectory1>$(StartDirectory)**\Release\**</AdditionalExcludeDirectory1>      <AdditionalExcludeDirectory2>$(StartDirectory)**\TeamBuildTypes\**</AdditionalExcludeDirectory2>   </PropertyGroup>   <PropertyGroup>      <ResultsFile>$(BuildDirectoryPath)\..\Drop\$(BuildNumber)\TestResults</ResultsFile>      <RunConfig>$(BuildDirectoryPath)\$(TeamProject)\Nightly Build\Sources\MySolution\localtestrun.testrunconfig</RunConfig>      <Publish>http://myTeamFoundationServer:8080</Publish>      <PublishBuild>$(BuildNumber)</PublishBuild>      <TeamProject>$(TeamProject)</TeamProject>      <Platform>Win32</Platform>      <Flavor>Debug</Flavor>   </PropertyGroup>   <Import Project="RunTests.Targets"/>    <Target Name="Test">       <!-- Execute All Tests -->      <Message Text="Running Execute All Tests..." />      <CallTarget Targets="ExecuteAllTests" ContinueOnError="true"/></Target> Notes: (a) the localtestrun.testrunconfig is important because it tells MsTest what code coverage it wants.(b) This (code coverage) only works against the final (current) RTM version of Team Foundation Server (not Beta 3 or RC).(c) RunTests.Targets must be in the build directory (checked into Source Code Control with your build.proj)(d) If you get an exit code 1 from MsTest when your MsBuild runs then some of your tests failed.(e) Nightly builds are scheduled service tasks that cannot run User Interface dependant tests. For that you will need to buy Visual Studio Team Suite or Test Edition (as opposed to the Developer edition that your probably using) ... or implement something else (we use TestComplete 4 (1/8 ~1/10 the cost of the Visual Studio equivalent for way more functionality) and a bank of Virtual PCs for UI testing) Some hints: <PropertyGroup> define variables that you want the MsBuild run to know about. The ones I listed are those used by RunTests.Targets. <Target> are steps that MsBuild knows about. If you find the file "Microsoft.TeamFoundation.Build.targets", open it and collapse all the Target nodes, you will see all the targets that MsBuild knows about from it defaults configuration file. CallTarget Targets="ExecuteAllTests" calls the articles code in the "RunTests.Targets" file. That was a quick brain dump ... I hope that it helps and I'm not too rambly Paul.

关于SQL SERVER 日志满的处理方法关于SQL SERVER 日志满的处理方法

手把手教你开发Facebook 应用

用户体验

Recommended Books for BEC BEC 推荐书目

界面设计规范

出色图形用户界面（GUI）设计规范