After upgrading my TFS 2010 installation from Beta 2 to RTM I noticed that my build agent stopped working. I also noticed that I was unable to delete the build agent with an error message along the lines of "Cannot remove build agent [agent name] from build controller because it is currently reserved for a build".
I'm pleased to announce that I finally figured out how to resolve the issue.
In SQL Server Management Studio connect to your team project collection db (tfs_[collection name].
Execute the following SQL statement:
SELECT * FROM tbl_BuildAgent
Locate the build agent in question then note the value of ReservationId and AgentId.
Execute the following SQL statements:
DELETE FROM tbl_BuildAgentReservation WHERE ReservationId = [ReservationId]
UPDATE tbl_BuildAgent SET ReservationId = NULL WHERE AgentId = [AgentId].
Once that was done I was able to successfully remove the Build Agent from TFS Admin Console.
For any and all developers that have an addiction to learning and problem solving I give you (drum roll please) Sleep Can Wait...
Tuesday, July 20, 2010
Tuesday, March 23, 2010
AppDomain.CurrentDomain.BaseDirectory and MSTest
I have become a big fan of using XML files to store lists of data. Specifically when that data is to be displayed via the presentation layer of my application(s). While writing an extremely simple unit test just to verify that it works I discovered what I thought to be a crucially bad design to MSTest:
AppDomain.CurrentDomain.BaseDirectory returns the directory where your assemblies are copied during test execution, not the "real" base directory.
Let's look at an example.
I have a class BaseDocumentLocater that attempts to retrieve an XML file and an associated XSD file from AppDomain.CurrentDomain.BaseDirectory. The files are marked as Content and are always copied to the output directory (ie. bin if your running in the visual studio web server or IIS). Assuming that your application lives in C:\Source\MyApp then your runtime AppDomain.CurrentDomain.BaseDirectory would be C:\Source\MyApp\bin.
However, when you're running MSTest then your BaseDirectory would be something like this:
C:\Builds\MyApp CI Build\{builder number}
This wouldn't be an issue except for the fact that only dlls, pdbs, and config files are copied to this directory. This means that my XML / XSD files wouldn't exist when BaseDocumentLocator tries to locate them in AppDomain.CurrentDomain.BaseDirectory\{fileName}.
Needless to say I thought this was quite perplexing and a really terrible design. I googled and binged and even yahoo'd for several hours. I mulled over every setting that I could find and nothing seemed to present itself. I actually got to the point of attempting to set BaseDirectory in my unit test! Right before I got officially fed up and turn in for the night I noticed that my application had no testsettings document. I decided to add one and check out the settings. To my dismay there was nothing in there that seemed to offer a solution. Being the good little Test Driven Developer that I am I ran all of my tests one last time and auto-magically the tests passed! BaseDocumentLocator found the XML files! I thought this was very odd to say the least. I debugged the unit tests in question and my jaw nearly hit my desk when I saw the value of BaseDirectory was back to the bin folder! WTF?! Was I going crazy? I hadn't been drinking. I know that these tests were failing but all seemed to be working now. On a hunch I deleted the testsettings file and re-ran the tests. They failed. BaseDirectory was now the returning the build directory again. Needless to say, adding the testsettings file again resolved the issue.
The point of this post is to save some poor schmuck a few hours of pounding his or her head on their desk if and when this issue presents itself. Are you that schmuck?
Subscribe to:
Posts (Atom)