Excluding Built Types from Alerts

Friday I got a question from one of my colleagues asking how to exclude a particular Build Type from their Alerts. I knew it could be done, but wasn't sure exactly what the proper filter would be. Thanks to Jason Prickett's blog post for some general guidance, I think we figured it out.

The easiest way to do this is to use Power Tools "Alert" interface which shows up under a Team Project in Visual Studio's Team Explorer. Simply add a 'DefinitionPath = '\TeamProject\TeamBuildType' clause. Add Or clauses if you have more than one Build Type in a Team Project you want to grab.

For those of you using Teamprise, you can install the free Visual Studio Team Explorer and use the command line tool called BisSubscribe. You can use BisSubscribe from the command line to run something similar to this:

bissubscribe.exe /eventType BuildCompletionEvent2 /server http://tfs.mycompany.com:8080 /address firstname.lastname@mycompany.com /deliveryType EmailHtml /filter "\"TeamProject\" = 'TeamProject' AND "DefinitionPath" = '\TeamProject\TeamBuildType'"

Hope this helps.

TF214007: No build was found with the URI

After making some changes to our build machine, we started getting the following error. I got asked to look into the issue and became immediately confused.

Exception Message: TF214007: No build was found with the URI vstfs:///Build/Build/14365. Either the URI does not exist, or TLR\svcTFSService does not have permission to access it. (type BuildNotFoundForUriException)

I was able to log onto the build machine and hit the PROD URL for build 14365 just fine. So I knew it couldn't be permissions. What was it? I said while scratching my head.

Six months back we migrated our TFS instance from DEV hardware to PROD data center hardware. As part of that process, we updated the DEV's Instance IDs so we didn't run into conflicts when trying to hit either site (we continue to use DEV for testing).

While any new connection to DEV would get the new Instance IDs, the legacy connections on our build servers still had the cached version of DEV's Instance IDs, which just so happen to be our PROD Instance IDs (as expected since we migrated from DEV to PROD).

So what was happing was, when someone was making changes to the build machine, they opened Visual Studio and got connected to DEV by mistake. DEV, using the cached Instance IDs (again which were PROD's), became the active TFS server somehow. So when team Build was firing off, it was actually hitting DEV, which obviously didn’t have a build URI 14365. Thus the error.

To fix this, we deleted the TFS cache on the build server. Then to test it, we purposely logged into DEV and checked our local cache. Sure enough, the new DEV entry in the cache had the new Instance IDs. All was well after that.

Check in comment to dynamically enable or disable CI builds.

I just got done adding in some custom MSBuild changes to automatically check in a Jar file to another build type (i.e. MainBuild in this example) after the Jar file build type (i.e. CommonBuild in this example) is finished.

Buck showed me a really cool way to "enable" or "disable" continuous integration (CI), which is turned on for us, in the MainBuild. That is, when CommonBuild checks in the Jar file to MainBuild, we can control whether we want to fire off a MainBuild.

First we set a Property called ExecuteMainBuildCIBuild to true|false. If true, we set the check in comment equal to /comment:"AUTO CHECKIN FROM TFS FOR COMMON JAR BUILT IN $(BuildNumber)". If false, we set the check in comment to /comment:"$(NoCICheckinComment)". $(NoCICheckinComment) resolves to the string ***NO_CI*** which tells Team Build to not fire a CI build.

End users can also use ***NO_CI*** if they want to control the CI build behavior. For example, if you're wishing to check in a change and not execute a CI build, you can simply put ***NO_CI*** in the Comments section. I'm not sure if management will enjoy us sharing this back door, however I've found it to be a valuable tool for solving some unique problems.

"Mac, how do I compile Java with Team Build?"

In the past week, I've fielded a number of questions from people within my company regarding how to get started compiling Ant based Java projects within TFS. Here is what I tell them. And it would be what I'd tell you if you asked.

My Colleagues: "Mac, can you provide us some information on how to get started using Team Build to compile our Java projects?"

Mac: "There are a number of different ways to solve the problem, but I'd suggest looking at Teamprise's Team Build Extensions. This is an open source project, supported by Teamprise, to run Ant scripts via Team Build (which is nothing more than MSBuild behind the covers). They have a very good tutorial (as part of the distribution if I remember) and support forum.

I'd start by trying to get one of your simpler Java projects to build. Then once you build that, you can get a better understanding of how the tooling can best solve your problem. What we do is have one parent Ant script that calls all the other tier Ant scripts. So basically Team Build is just the high-level driver and we let Team Build Extensions and Ant take care of the rest. This seems to work pretty well for both [MY CURRENT BUSINESS UNIT] and [MY OLD BUSINESS UNIT]. Also, I think if you have JUnit tests that you run as part of the build, and follow some simple rules, Teamprise Build Extensions will publish the results back to TFS. Pretty cool!
"

So if you're looking for help getting started, consider this my response to you. Let me know how it goes.

HintPath and Team Build

Very long week so I've got to keep this short. For some reason when a developer added a Reference to his csproj file it didn't add a <HintPath. The build worked locally and it worked on the build machine when we ran the build manually through Visual Studio. However, when trying to run the build via Team Build, we got the error "Could not resolve this reference. Could not locate the assembly." We could see that when Csc.exe was called, our Reference was not referenced.

The fix was to add a <HintPath to the csproj file. After doing that, Team Build ran fine and we could see it added to the Csc.exe Reference command line. I didn't get time to figure out why, but thought I'd document it here for when it happens again.

Using $(WebProjectOutputDir) in the *.csproj file's PostBuildEvent

A colleague of mine wanted to add a PostBuildEvent in their *.csproj file which would run a custom executable to create generated java script files.

The change (see BEFORE below) worked locally as the path they wanted the generated was $(ProjectDir) which mapped to the .\Sources directory on the build machine and their locally directory within their IDE. The issue was, we needed the generated files to be under .\Binaries on the build machine which didn't exist on their machine. More specifically, we needed this generated file created under $(OutDir)_PublishedWebsites\$(MSBuildProjectName) on the build machine which translates to .\Binaries\_PublishedWebsites\$(MSBuildProjectName).

What we ended up doing was, instead of using the $(Outdir) property, we used the $(WebProjectOutputDir) which was set in the $(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets file. Using this value allows the output directories to be correctly set on both the build machine (where we want to use .\Binaries) and $(ProjectDir) where we want to use the locally structure.

BEFORE:
"$(TargetDir)JavascriptFromMvcRoutes.exe" "$(TargetDir)$(TargetFileName)" "$(ProjectDir)js\Generated.js"

AFTER:
"$(TargetDir)JavascriptFromMvcRoutes.exe" "$(TargetDir)$(TargetFileName)" "$(WebProjectOutputDir)js\Generated.js"

Changing TFS Build Agent to look at a different TFS Server

Just because I continue to forget; if you need to change the TFS Server for your TFS Build Agent, change the add key="AllowedTeamServer" value="http://tfs.mycompany.com:8080/" element in the C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\tfsbuildservice.exe.config file. Then bounce the TFS Build Agent via Services.

We have seen some instances where this change does not take affect right away. We even bounced the agent more than once with no affect. Oddly enough, when we got back from lunch everything was working. My assumption is that the agent uses a cache and that was not getting refreshed. Either that or heading to lunch fixes most everything ;).

Check out SdcTasks

We've taken a mass adoption of the SdcTasks found on Codeplex. When comparing MSBuild to Ant, I've always been disappointed with the Core tasks in MSBuild. The default list seems to be limited. NOTE: I have not done a task for task comparison, but only a cursory compare.

The limited task set in MSBuild is what has really excited me about SdcTasks. There is a ton of stuff in this add in. Want to talk to Active Directory, Email, or talk to SQL? Take a look at SdcTasks for help.

Since I'm lazy, I'd like to see these rolled into the standard install for Team Build or MSBuild.

Team Build hangs when using Pstools and the Exec task

In my new position they have given me deployment. Basically after the build and unit tests are run, they want the code deployed to the servers. We're running under IIS 7 so I've decided to write the deployment logic using AppCmd from the IIS 7 team. It looks like a very nice tool!

To execute the series of AppCmd commands (actually we've grouped them into a batch file that we call) we're using yet another Microsoft technology called Pstools. In this suite of tools there is psexec which allows you to execute remote commands. After we got past some odd domain --> workgroup permission errors, it works pretty well. The command we use is something like this "c:\tools\pstools\psexec /accepteula \\server cmd.exe /c c:\deploy\install.bat 0.0.25"

Back in our TFSBuild.proj file we're using the Exec task to execute this. Unfortunately the Exec task hangs. "Gonzobent" has submitted a wonderful write-up on this to Connect. I added my two cents in as well.

To get around this (as we need to so our deployment efforts can continue) we put the "non-interactive" switch (i.e. -d) on the psexec command. So now the command looks like this "c:\tools\pstools\psexec -d /accepteula \\server cmd.exe /c c:\deploy\install.bat 0.0.25". This is not ideal as we don't get any output back in the Team Build log file to see if the deployment works or not. We just assume it does - since I wrote it ;)

As I put in my comments on Connect, I think psexec is sending back MSBuild information it's not expecting. We ran into this a few years ago when we wrote a homegrown build system which had a Java application as it's Built Client. When a user ran a Ant script that failed, the system would just hang. There is a good article here that examples how we fixed it. We basically thread reading the output and error.

If anyone has any other work around ideas, please let us know.