Ta. Steve Porter

One of the processes we use here at Imaginet is to create a special team build for the QA team to control. This special build is configured to deploy to the QA environment and is manually ran by the QA team whenever they want to begin a new testing cycle. By using a separate build, the QA team can easily gather quality metrics and build statics for their QA cycle since these QA metrics aren't muddied up by the daily development activities that drive most of our team builds. It also ensures that the testing environment isn't accidently clobbered by the dev team (like that's never happen to you :) .

Our routine goes something like this...

1. Development team works like mad for an iteration to prepare a end of iteration QA build for the QA team.
2. Development team decide which one of their team builds they wish to send to QA for testing.
3. The development team locates the completed team build in the Build Explorer and sets the build quality to Ready for Initial Test.
4. The QA team automatically receives an e-mail via the built in Project Alert. This e-mail contains the build's label.
5. The QA team manually queues their End of Iteration team build and supplies the build label as an MSBuild command line argument. The syntax is /p:GetVersion="Llabel@$/Team Project".

Using this special syntax allows the QA team's build to ignore the latest source files (which may have changed since the dev team built their testing candidate) and instead use the exact files that the dev team has authorized.

Do you have any special processes you use for your QA team to help them build their testing environment?

Ta.
Steve Porter

One of the useful features in the 2008 Team Foundation Server powertools is the ability to delete work items (DestroyWI). With Team System 2005, the best you could do is to hide work items by changing it's state, but there are valid cases for wanting to get rid of errant work items entirely (created in error is my favourite).

Unfortunately, one shortcoming of this powertool features is that the data still seems to show up in the reports. We had this issue occur this week and it was totally screwing up one of our reports. I did a quick bit of digging to see what the issue was and it seemed that the work item was removed from the relational data stores, but not removed from data warehouse that provides data for the cube (which is what the reports use). I queried the data warehouse and could still find the delete work items. Not Good.

Cleaning it up wasn't a major issues, but still a bit of a pain in the butt. To clear the warehouse I used the SetupWarehouse command line utility. The documentation on this command is a little spotty, so here's the command I issued...

"SetupWarehouse -s [DatabaseServer\Instance] -d TFSWarehouse -c warehouseschema.xml -a [domain\TFSService account] -ra [domain\tfsreports Account] -mturl http://server:8080 -rebuild -edt TfsBuild"

This caused Team Foundation Server to rebuild the warehouse and flush all of the current data. The next time the data adaptors ran, the warehouse got populated. Then, the processing service recreated the cube and that allowed the reports to display the correct data. You can force a lot of these actions by calling the warehouse Run webservice. To perform this action. Use a web browser to navigate to http://[your server]:8080/Warehouse/v1.0/WarehouseController.asmx, then select the Run method, and then select Invoke.

A word of warning, the data adaptors took a long time to run, so don't expect to see immediate results.

Has anyone else observed this 'feature' of DestroyWI?

Ta.
Steve Porter

One of the items that came up during my last training sessions was how do you ensure that the bug that Team Build creates automatically for you when a build fails, is assigned to the appropriate user.

By default, when a build fails (and this has to be a compile failure, not a test failure), a bug work item is created to assist in tracking the work required to fix the build. The system automatically assigns the bug to the user that requested the build.

Now, this behaviour is great for continuous integration builds, but it's not so good for scheduled builds. Scheduled builds are run under a special build account and by default, it's this account that the bug gets assigned to.

The key to changing this behaviour is to adjust the MSBuild .proj file and add a line that associates the user you want to assign to. Here's the syntax:

<WorkItemFieldValues>Assigned To=Steve Porter;System.Reason=Build Failure;System.Description=Start the build using Team Build</WorkItemFieldValues>

I've created a web cast that walks through the entire process. It's close to 13 minutes in length, but if you want to go right to the implementation and see how it's done, you can just jump to about the 6 minute mark of the web cast.

Have you customized the bug creation any further? If you have, please leave me a comment to share your experiences.

Ta.
Steve Porter

I was recently asked by a client how to ensure that the Assigned To drop down that appears in most work items can be filtered so that it doesn't include every user on the server.

This is quite an easy task, and it's one that I do for every project that I work on.

The key to only including team members in the Assigned To drop down is to edit the work item and change the rule for the assigned to property from ValidUser to AllowedValues and use "[project]\Contributors" (or some other group) for the rule's list item.

To make this explanation a little easier to consume, I’ve created a really quick web cast that walks you through the steps.

I hope you find it useful.

Ta.
Steve Porter

I've placed my webcast on the web for those of you who may have missed the live broadcast. You can access the files here. Once you uncompress the archive, you can just open the ReplayMeeting htm file in IE and you should hopefully be good to go. I had issues watching in Safari, so for you mac user's out there you might have to resort to using a virtual environment. Sorry.

Let me know what you think of the content? Too light, too heavy? Anything you'd like to see in an upcoming web cast?

Ta.
Steve Porter

I want to thank everyone who watched my web cast on customizing process templates. As promised, I've posted the files that I included in my demo here.

Here are the resource links from my slide deck:

MS Guidance

Powertools
for 2005
for 2008

I'll post the address of the recorded web cast as soon as it's available.

If you have any comments or questions, please feel free to contact me via e-mail or you can leave me a comment below.

Ta.
Steve Porter

P.S. This is the first in a series of web casts. Joel Semeniuk has posted additional details here. Have a look at the schedule and try to attend.

Join me Wednesday May 14th at 12:15 Eastern for a 30 minute web cast titled Customizing Team System Process Templates. I'll be covering the basics during this web cast, but you will learn enough to make powerful modification in your own environments.

You can register for the Live Meeting web cast by visiting this URL.

Hope to see you there.

Ta.
Steve Porter

I've gathered up everyone's suggestions and built what I think to be a pretty good course syllabus. You can view the offering here

Thanks to everyone who took the time to provide me with some feedback. Your responses were very helpful and allowed me to focus on the items that people said would be the most valuable to them.

Now I just have to gather the material...

Keep an eye here for further details on when the course will be available.

Ta.
Steve Porter

I was reading a couple of blog posts (here and here) about the new unit testing framework on the block (xUnit) and it got me thinking about one of my pet peeves.

Why is it that smart people need to prove that they're smart by taking an established idea, tweaking it a bit to add improvements, but in the process, they make major changes to the terminology so as to add a whole new set of vocabulary to the conversation.

My lovely wife has said to me on many occasions that words matter. So why muddy up the waters with a new set of terms? It's easier if everyone is talking the same language. Steve's first rule: Keep It Simple.

I've often gone off on a good rant about how Microsoft did itself (and their customers) a big disservice when they choose to make their unit testing framework just different enough so that it breaks compatibility with NUnit. This forces an organization to choose one testing framework and then once they do, they are pretty much stuck with it. Converting existing tests from MSTest to NUnit is a bit of a pain that would have been a lot easier if they had used the same terminology. Now xUnit has taken the same crappy road. That's too bad. Now if I want to use their framework I have to learn a whole new set of terms and my tests are hard-coded to a particular framework. Bleech.

Just an observation here, but making up new terms for common ideas does not make you look smarter (Scrum's use of the term Sprint come to mind). Maybe the folks in marketing think that it's important that your company sets themselves apart from their competition, but the folks in marketing are evil and don't care about making things easier for everybody. The industry landed upon the common terms for a reason, now suck it up and stick to them. Spend the time you spent coming up with the nifty new term doing something that's actually useful.

Ta.
Steve Porter

I've been thinking a lot about unit tests lately. Anyone who's heard me speak knows that I'm very passionate about unit testing. I believe that it is the number one thing that an organization can do to improve how they develop software. Period.

But I still find a lot of organizations that haven't started down the unit-testing road. Here are some of the things I hear:

• We don't know how to get started.
• We don't have any testing expertise in our organization.
• Our code is too hard to test.
• What are some best practices we should follow?
• Do you think that being a Mac user makes you cool?

(OK, that last one had nothing to do with testing, but I still hear it all the time and the answer is yes! I was totally uncool until I bought my MacBook and just having it in the same room with my doubles my cool factor).

The above comments are all valid, but I think that unit testing is so important that organizations need to stop finding excuses and just start doing it. With that in mind, I'm considering creating a course (3 days long maybe?) that would help an organization adopt unit testing and hopefully get off on the right foot. Here are some of the topic areas that I'm considering:

1. Learning unit testing fundamentals
2. Determining what unit testing framework is right for your organization
3. Writing your first unit test
4. Getting started using unit tests in your organization
5. Writing the right unit tests, the right way
6. Planning for unit testing in your project planning
7. Using advanced Asserts
8. Using external data input in your unit tests
9. Writing testable code
10. Writing maintainable tests
11. Dealing with legacy code
12. Using mocking frameworks
13. Determining what mocking framework is right for your organization
14. Testing databases
15. Testing code that accesses a database without actually accessing the database
16. Integrating unit testing into your build
17. Choosing what unit testing add-ins and utilities to use
18. Leveraging unit tests in your production environment
19. Unit testing mobile applications
20. Unit testing Windows Workflow applications

I'm picturing a very hands-on course where you learn by writing unit tests against real looking code.

Does that list of topics get you excited? Is this something that your organization would find useful? Drop me a comment or an e-mail to let me know.

Ta.
Steve Porter

Imaginet will be hosting a series of webinars on various .Net topics during the months of May, June and July. Here's a list of topics, presenters and dates:

Topic	Presenter	Date
Customizing Team System Process Templates	Steve Porter	14-May-08
Introduction to Software Factories	Robert Regnier	21-May-08
Windows Communication Service Gateways with C # 3.0 and Linq-To-SQL	Dave Harris	28-May-08
Testing out the MVC: Routing	Ryan Weppler	04-Jun-08
Customizing Software Factories	Robert Regnier	11-Jun-08
Dependancy Injection with StructureMap	Jeremy Wiebe	18-Jun-08
Nhibernate: An Entry-Level Primer	Dave Harris	25-Jun-08
Creating Real world applications with CSLA 3.5	David Maynard	02-Jul-08
MVC vs MVP smackdown	Robert Regnier	09-Jul-08

Each webinar will begin at 12:15 Eastern and be very easy to consume (30 minutes max). Low on the powerpoint slides, high on code demonstrations. I'll post updated information once it becomes available, but please mark these dates on your calendar and try to make time to attend.

Ta
Steve Porter

Brian Harry just announced the items that are going to be included in Team Foundation Server 2008 SP1. Wow!

I've always believed that the dev team working on TFS has done a really great job of dogfooding the whole agile delivery model that they push with the MSF process templates and this service pack speak to that.

This isn't just a bunch of bug fixes, but a whole whack of new features. Here are a couple of highlights for me:

1. Simpler working folder mappings: One of the hardest concepts that Visual Source Safe users have when they first start working with TFS is Workspaces. Hopefully this new interface will help ease the transition.
2. Conditionalize builds on the trigger: This feature would have saved me from having to create and maintain multiple script files for one of our projects that had a large number of slow tests. This would have allow me to skip the slow tests for my CI builds, but keep them in for our nightly builds.
3. Automatic solution rebinding: I've always hated the manual grunt work that follows any large scale VSS migration. Although I always recommend that teams take the migration process as an opportunity to clean up their source tree structure, for teams that just want a simple migration, this will be a great time saver.

Keep up the good work!

Ta.
Steve Porter

Want to get started evaluating Team Foundation Server 2008? Here are some concrete steps you can take this week-end.

1. Download the Team Suite Trial VPC from Microsoft. It's a pretty hefty download, but well worth the bandwidth.
2. Make sure that you also download and install the VSTS 2008 Hands-on Labs March 2008 Release. This is the last download in the list of files to download on the page noted above. Installing the labs right on the VPC makes the most sense, as they go hand-in-hand.
3. Download and install the Scrum process template from Conchango. Ensure you get the version for TFS 2008. The template must be installed on the VPC using the TFSSetup account. The install is very straight forward on the VPC (next, next, next). Once installed, you can create a new team project with this template to experiment with. The steps for creating a new team project can be located here. Make sure that in step 4, you select the Scrum template.
4. Review some of the existing process guidance documentation:
• MSF for Agile - On the VPC, open Internet explorer and navigate to http://tfsrtm08/Sites/Module03/Process%20Guidance/Supporting%20Files/ProcessGuidance.htm
• MSF for CMMI - On the VPC, open Internet explorer and navigate to http://tfsrtm08/Sites/ebanking1/Process%20Guidance/Supporting%20Files/ProcessGuidance.htm
• Scrum - On a machine connected to the internet, open Internet explorer and navigate here.

If you have issues access the process guidance on the VPCs, log into the site using the TFSSetup credentials.

5. You can learn the basics for navigating Team System by following the lab named "Team Development with Team System 2008". If you performed the default install of the labs mentioned in item 2, then the lab is located in "C:\MSLabs\VSTS 2008\Manuals\e2e".
6. Most of the team projects have been created using the "Agile" template. if you wish to see that the CMMI template looks like, you can view the eBanking1 Team Project.
7. Review some of the available reports by reviewing the hands on lab "IT Governance with Team System". If you performed the default install of the labs mentioned in step 2, then the lab is located in "C:\MSLabs\VSTS 2008\Manuals\e2e".
8. Explore the web front-end to TFS. It's already installed on the VPC, so you'll just have to navigate to http://tfsrtm08:8090 and kick the tires.

Hope this helps you get started evaluating Team System. If during your evaluation, you have any questions or thoughts, feel free to leave me a comment.

Ta.
Steve Porter

I spent some time with the TFS Migration and Synchronization Toolkit this week and I thought that I'd share my experiences with it to help out anyone else who wants to evaluate this toolkit. I found the included documentation to be a little weak and in some areas if found that parts were missing, so maybe this post can fill the documentation out a bit.

I had a pretty simple goal in mind when I started looking at the toolkit. I just wanted to run a simple demo where I synchronize a SharePoint task list with work items in a Team System project. The toolkit includes the required pieces to make this happen, but the additional undocumented steps I had to perform were a little frustrating (and time consuming as I had to hunt down solutions to my issues). So here are the steps I took to get this simple demo working.

I was working on the newly released Team Suite Trial VPC from Microsoft, so I was working with both Visual Studio 2008 and Team Foundation Server 2008.

I started by logging into the VPC as Darren (an account with local administrative privileges).

Once logged in, I decided that I was going to work with an existing team project (eBanking1). If you want, you can work with a new team project, but of course, you'll need to create it first.

The code included in the toolkit sample uses a custom work item, so the next step I needed to perform was to import the work item (since the toolkit team was so nice to include the work item definition xml file (WssTask.xml located in WIT\Wss2TfsWit\). I initially experienced some issues importing this work item (this may be a 2005 vs. 2008 issue), but a few adjustments to the .xml file and I was golden.

First, replace line 2 with the following:

<WITD xmlns:witd="http://schemas.microsoft.com/VisualStudio/2005/workitemtracking/typedef" application="Work item type editor" version="1.0">

and replace line 210 with:

</WITD>

Next, add the following field definition somewhere in the field definition area (I started at line 43):

<FIELD name="History" refname="System.History" type="History">

<HELPTEXT>Discussion thread and other historical information</HELPTEXT>

</FIELD>

Once I made those edits, I used the Process Template Editor to import the work item into my target team project (you've all downloaded the TFS 2008 PowerTool, haven't you? If not, shame on you and go get it from here ASAP).

The next item that needed to be taken care of was the creation of the database used by the migration tool. The required SQL scripts are also included with the toolkit and can be located in 'Toolkit\Wit\SQL\'. I used the installed instance of SQL Express to host my database, but you can use any SQL Server database. Before I could run the scripts, I needed to manually create the database (called MigrationToolkitTest) and once it was created, I just ran the two included scripts (first the script to create the table definitions and then the script to create the stored procedures).

Next, I logged into the team project's portal and ensured that the current user permissions allowed full control over the SharePoint site (see here for details).

Once the user had the appropriate SharePoint permissions, I added the currently logged in user to the TFS Server Account group using the TFSSecurity utility (syntax = tfssecurity.exe /server:http://yourserver:8080 /g+ srv: domain\account).

Now that all of the appropriate permissions were assigned, I needed to get the included code built. First, I opened the solution located in the Toolkit directory. If you're running Visual Studio 2008, you will be prompted to convert the solution, which was quite painless.

Once converted, I needed to make a few adjustments to get the solution to actually build. I'm going to assume that the C# compiler has been changed between 2005 and 2008 and that the build errors I was getting don't show up in 2005. The changes that I had to make involved changing the scope of a couple of property get statements. In both statements, the property was scoped as protected and I changed them both to be public. Both lines are found in the file named ChangeGrouping.cs (one on line 126 and one on line 286).

Once those changes were made, I was able to build the solution, but there were a few other changes that I needed to make to address a known issue.

1. Move FireEvent(SessionStart, MigrationToolkitResources.SessionStarting call) right after initializing m_syncProcess member in Synchronize, SynchronizeFull and ProcessDeferredLinks method located in WorkItemTrackingSession.cs
2. Move FireEvent(SessionAborted,...) in AbortImpl method right under m_syncProcess.Abort() call located in WorkItemTrackingSession.cs

Once those changes were accomplished, I was able to build the solution and produce all of the executables and dlls required. If you're planning on running the solution via the command line executable, you will need to copy all of the dll output from two projects (TfsLinking and Wss2TfsWIT) to the same directory as the console application. If you want to debug the solution from inside Visual Studio, you can make sure that the console application project references the two previously mentioned projects so that the output gets automatically copied to the output directory of the console application. One additional step you'll need to perform to allow debugging is add a call to the SampleConfig.xml to the Command Line are in the Debug property.

Speaking of the SampleConfig.xml file, the included documentation mentions a few areas where you'll need to make edits, but I'll expand on those instructions a bit.

First, since I only wanted to synchronize the task list and not worry about version control or linking, I removed both the <VC> sections and the <Linking> section (careful to leave the closing </Sessions> tag at the end of the <Linking> section).

I then edited the WIT section to use my test project (eBanking1) and changed the <BaseURL> to point at the team project's portal (eg:http://tfsrtm08/Sites/eBanking1).

I adjusted the Server section to point to my actual server (replacing where id=SampleTFS)

I adjusted the SQL section to use SQL Express by change the connection string to use '.\sqlexpress' and made the same edit to the <Server> property.

Once those changes were made to the SampleConfig file, I was able to run the command line application without error. To test the toolkit, I opened the team project portal's task list in Internet Explorer, added a couple of tasks and then ran the console application. Once completed, I used the team explorer to query for WSSTask work items and discovered my newly added SharePoint tasks had been copied over to WSSTask work items. I could then go and make changes to the tasks in SharePoint, rerun the console application and the changes would be reflected in Team System. Pretty cool.

I'm still dealing with a couple of problems. It looks like I'm having issues with the time set in SharePoint and the time synchronized in the corresponding work item in Team System and I get errors after creating more then 2 tasks, but I'm sure that these issues are just me being unfamiliar with setting up the toolkit. Hopefully I have these issues addressed with a little more digging.

Have you had any experiences with this toolkit that you'd like to share? Any successes or issues that you've encountered? Leave me a comment to spread the word (both good and bad).

Ta.
Steve Porter

One of my co-workers was having a difficult time creating work items using the 2008 version of the Team Explorer on Vista. Saving a work item would take more then 40 seconds and at times range as high as 2 minute. Totally unacceptable.

We ran the TFS Best Practices Analyzer, but it didn’t discover any issues. We tried using Excel to see if it would help, but he still received the same poor results.

While trying to troubleshoot the issue, my co-worker disabled IPV6. Success! All the performance issues disappeared. I wish I had thought of that.

I had heard that enabling IPV6 can cause unusually behaviour, but since I’m not often running Vista these days, it didn’t even occur to me.

Good catch Joel!

Have you ever struggled with TFS or VSTS performance issues and had some successes fixing the issue? Leave me a comment so you can share your success story with the world.

Ta.
Steve Porter

This couldn’t have come at a better time.

The old VPC (which I use for presentations) was set to expire on April 1st (this upcoming Tuesday) and I needed a replacement. I been working on creating my own VPC for an upcoming session I have in Salt Lake City and I was starting to get worried that I wasn't going to get everything installed and configured on time.

Thanks to everyone involved at Microsoft for getting this released before the old VPC expired.

You can download all of the files here. The image is set to expire at the end of 2008. Lots of time to explore all the tools available. Also included is a collection of hands on labs that explore the features of Team System. I'm interested on what they cover.

Was anyone else getting worried about their old image expiring? Did you make good use of the old image?

Ta.
Steve Porter

One of my customers reported receiving this error when trying to create a new team project on their new 2008 Team Foundation Server.

One of the strange things was that this wasn’t the first project that they’d created on this server. Other projects were created successfully.

After a bit of troubleshooting, I discovered that the issue was caused by trying to use the 2005 Team Explorer to create the Team Project. Switching over to the 2008 Team Explorer client fixed the issue. No points to Microsoft for the obtuse error message.

This brings up a good question. At Imaginet, we decided to perform a clean install of 2008 and use it for all new projects but keep our 2005 server around for existing projects. Because of this, we have users who have to jump back and forth between the 2005 Team Explorer and the 2008 Team Explorer. How many of my readers have upgraded to Team Foundation Server 2008?

Ta.
Steve Porter

I’ve been working to get our new Team Foundation Server up and running at Imaginet and one of my tasks was to take an existing project and migrate it over. This has been a mostly pain free procedure, with one team build related exception.

One of the tasks that this project’s team build is performing is to take the build output and deploy it to a testing environment. This involves stopping a set of services, performing a file copy and then starting the services back up again. To assist with these tasks, the build was using a couple of tasks from the MSBuild Community Tasks Project (specifically the StopServices and StartServices tasks). This worked without a hitch with our 2005 build machine, but when I migrated this script over to our 2008 build machine, the build started failing on these tasks. Weird.

One of our staff (thanks Mike) started to investigate and came across an unexpected “feature” of the new build agent. I’ll let him describe the issue…

In my build type, I want to shut down and restart some services on my build server. I was able to do this in VS 2005 Team Build successfully: <Target Name="StopServices"> <Exec Command="sc stop &quot;Support Service&quot;" Timeout="60000" ContinueOnError="true"/> <Exec Command="sc stop &quot;Client Service&quot;" Timeout="60000" ContinueOnError="true"/> </Target> When I log on as the tfsBuild service on the build machine, and run the above build target using MSBuild, it works fine. Target StopServices: sc stop "Support Service" SERVICE_NAME: Support Service TYPE : 10 WIN32_OWN_PROCESS STATE : 3 STOP_PENDING (STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN) WIN32_EXIT_CODE : 0 (0x0) SERVICE_EXIT_CODE : 0 (0x0) CHECKPOINT : 0x0 WAIT_HINT : 0x0 sc stop "Client Service" SERVICE_NAME: Client Service TYPE : 10 WIN32_OWN_PROCESS STATE : 3 STOP_PENDING (STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN) WIN32_EXIT_CODE : 0 (0x0) SERVICE_EXIT_CODE : 0 (0x0) CHECKPOINT : 0x0 WAIT_HINT : 0x0 When I queue a build to occur on the same build server using Team Build, it fails. Target "StopServices" Task "Exec" Command: sc stop "Support Service" [SC] OpenService FAILED 5: Access is denied. Done executing task "Exec". Task "Exec" Command: sc stop "Client Service" [SC] OpenService FAILED 5: Access is denied. I then ran the following at the command prompt: whoami /all /fo list > c:\whoami-desktop.txt Then I added this task to the target "StopServices" (seen above): <Exec Command="whoami /all /fo list > &quot;c:\whoami-teambuild.txt&quot;" /> Removing all the identical information in whoami-desktop.txt and whoami-teambuild.txt, the remaining group information is different: whoami-desktop.txt: Group Name: BUILTIN\Remote Desktop Users Type: Alias SID: S-1-5-32-555 Attributes: Mandatory group, Enabled by default, Enabled group Group Name: BUILTIN\Administrators Type: Alias SID: S-1-5-32-544 Attributes: Mandatory group, Enabled by default, Enabled group, Group owner Group Name: NT AUTHORITY\INTERACTIVE Type: Well-known group SID: S-1-5-4 Attributes: Mandatory group, Enabled by default, Enabled group whoami-teambuild.txt: Group Name: NT AUTHORITY\SERVICE Type: Well-known group SID: S-1-5-6 Attributes: Mandatory group, Enabled by default, Enabled group These tasks worked when I was using Team Foundation Server 2005 and its Team Build service.

The answer in getting these tasks to work lies in using the Interactive Build feature of Team Build 2008. Team Build now uses WCF to communicate with the build agent and it doesn’t seem to be as loose with the permissions as the .Net Remoting based Team Build.

The only downside of using an interactive build is that I have to leave the account that is hosting the Team Build process logged in at the console and if the machine reboots, I have to log in and re-run the build process to make sure the build doesn’t fail. I could probably automate the login and process launch, but for now, everything seems fine.

Ta.
Steve Porter

I discovered an interesting feature with the new Create Team Build Definition dialog for Team Foundation Server 2008.

With TFS 2005, I was used to having to specify what drop folder to use for the build output. This information was gathered when you ran the Create a New Team Build wizard and was then stored inside the Team Build .proj file.

With TFS 2008, a lot of the data stored in the .proj file has been moved out of the proj file and into the Team Build database and the drop location was one of those pieces of information that was moved.

So I expected to have to set the drop folder during the wizard process in 2008, but I was never prompted to provide that information. I was able to provide a drop location if I queued the build manually, but there didn’t seem to be any way to set a default.

After a bit of playing around, I discovered that Microsoft decided to change the terminology slightly for 2008. You now set the default drop location by providing a staging location (see image 1).

image 1

Once set, the build agent will drop all of the output to this location by default.

Ta.
Steve Porter

I came across this issue while installing TFS 2008 this week. Our client wanted to use an existing install of SQL Server instead of having to maintain a new instance and everything seemed fine until I began to install TFS. I received the dreaded Error 29112 (Report server service not configured properly).

Reporting Services installed fine (or so it seemed), and the configuration window showed a lot of green checks, but there was an initialization issue.

After a bit of digging, I determined the issue. The client had installed the developer edition of SQL server and I had used the Standard edition to install Reporting Services on the app tier.

Unfortunately, the only way to fix the issue was to uninstall the standard edition and then install the developer edition.

Once that was done, all was good.

So, lesson learned… Always check the SQL edition on the data tier before installing Reporting Services on the data tier.

Ta.
Steve Porter

I spent part of this week-end doing a dry run in preparation for moving our production Team Foundation Server from it's current home on a low powered glorified desk-top machine to a virtual PC hosted on our kick-ass virtual server environment.

In defense of the old environment, it would have been robust enough for our needs, but when the machine was originally built, someone decided that it would be a good idea to partition the machine's huge hard drive into two partitions and the C drive was only allotted 6 gigs of space. Don't do that.

I followed the published documentation for the process and except for 3 issues it went fine.

Issues.

1. I needed to install a SharePoint Services hot fix so that that the new environment matched the old environment. This issue occurred while I was trying to restore the STS_Content_tfs database and the error message I received was "The database schema is too old to perform this operation in this SharePoint cluster. Please upgrade the database and try again". To move beyond this, I just had to install WSS2003-KB924881-FullFile-ENU.exe. To confirm that this was the missing component, I used the Add/Remove Programs control panel plug-in with Show Updates turned on to compare the two environments for differences.

2. I needed to change one of the command line calls while trying to restore and verify Report Server on the new Team Foundation Server. Step 19 needs to be changed to include the -mturl parameter. The command line I had to used was

SetupWarehouse.exe -o -s newDataTierServerName -d newTeamFoundationDataWarehouseName -mturl http://newDataTierServerName:8080 -c warehouseschema.xml -ra TFSReportServiceAccount -a TFSServiceAccount.

Before this command line would work, I needed to start the TFS App Pool, which is detailed in steps 1 and 2 in the To restart services and verify operation section.

3. I needed to install the Scrum for Team System process template on the new server. I realized this after I noticed that one of our team projects was showing the nasty red x beside the Documents folder in the Team Explorer and the project portal for this same project was displaying an error message. Once installed, the red x disappeared and the project portal displayed correctly.

Now, I just need to do it for real and then rename the server to match our old environment.

Ta.
Steve Porter

I've been hearing about this tool for awhile and I have high hopes for it. One of the biggest hurdles facing companies that want to adopt Team System is not wanting to lose their existing investment in other tools that perform some of the same features that Team System performs (Issue Tracking, Source Control, etc.). Hopefully this tool will allow these companies to leverage their existing investment, but still get all of the goodness that Team System provides.

Ta.
Steve Porter

The guys over at .Net Rocks have posted a podcast (show #250) of the Team System Panel discussion held at TechEd. The panel had some great participants (including my boss Joel Semeniuk). If you wish to get some insight into how Team System is being used in the real world by the leading experts, give it a listen.

Ta.
Steve Porter

Well, I'm back from my two week stay in Beirut.

It was an absolutely amazing experience and I'd love to go back soon to continue my work.

I want to give a really big thanks to all the folks at IESC for having me out and for making my stay so pleasant. I also want to thank all of the students for making my sessions so enjoyable.

I've posted my journal on-line if you wish to get more detail. There's a lot in there, but if you're looking for some information on what I experienced while in Beirut, I think it's worth a read.

The main page can be located here and if you want to just jump to the first entry, you can access that here and then to get to the next day, click 'previous'.

Ta.
Steve Porter

Well, I left for Beirut today to participate in two weeks of training as part of an IESC Geekcorps sponsored project. I'll be holding two separate sessions over the two weeks focusing on using Team System to improve software development.

I'd like to thank everyone at IESC for giving me this opportunity and I'm looking forward to interacting with the people on the ground in Beirut. I'm going to to make sure that everyone involved learns something useful during my stay (including me).

I'm going to be presenting Microsoft's Optimizing the Software Development Lifecycle with Microsoft Visual Studio Team System (MOC 2631a). This is my first exposer to this material and it seems to be well thought out. It covers all of the basic components of Team System and gives the students an excellent hands-on experience with each area (Project Management, Architecture, Development and Testing).

This course focuses more on labs then on lectures which follows my philosophy for training engagements (Powerpoint is for girly men). I've been warned in advance that the setup for the training material can be a little tricky but I believe that the trainer that preceded me iron out all the bugs (thanks Ben).

I encourage everyone to investigate the IESC geekcorps web site and see if participating in one of their projects might interest you. I've been very impressed with how well I've been treated so far and I'm going to assume that things are not going to change once I'm on the ground.

Ta.
Steve Porter

I noticed this great post on Digg about 26 reasons why what you think is Right is Wrong. It contains a list of 26 effects or biases that effect the way we perceive or act.

The list is actually a good read for software professionals because there are a few nuggets in there that directly apply to software development. Here's my personal favorite...

14 - Information bias - the tendency to seek information even when it cannot affect action.

This is just another word for Analysis Paralysis. To combat this, you should consider the the Agile concept of doing just enough analysis to get you started and then continue to review your assumptions as you progress.

Or how about...

20 - Planning fallacy - the tendency to underestimate task-completion times.

Oh man, is that not the truth!

Have a look at the list and see if any apply to you.

Ta.
Steve Porter

Yesterday I attended an excellent seminar on Agile Development presented by Roy Osherove. One of the nuggets of wisdom that I took away was his suggestion on how to get your team to think about project risk.

Defining risk is hard. Very hard. Developers are optimist by nature (bless their little hearts). They all believe, that given enough resources, they can accomplish any task. So when you ask them to define the risks to a projects success, they're stumped. They assume that they'll be able to overcome any obstacle and succeed.

His suggestion was to get the team to hypothetically place themselves into the future, at the end of the project, after it's already failed miserably. You then get the team to describe what caused the project to fail. What a great idea! I think by getting the team to acknowledge that the project could fail (by mentally placing them into the future where the project has already failed), and it allows the team to be pessimistic without it being personal.

Ta.
Steve Porter

One of our clients brought this little beauty to my attention, so I'd thought I'd pass it along in case anyone else comes across this issue...

This client makes heavy use of Team Foundation Server's branching and merging feature. They have a main source root that they take branches from to work on and then merge their changes back into the root. All good so far. In addition to merging back to the root, these branches, on occasion, re-visit the root to pick up changes made to it directly or changes from other branches that have merged their changes to the root. They do these occasional syncs to make the eventual final merge to the root less painful and to insure that their branch is up to date. Everything was working great until one merge started causing them grief. Here's the detailed explanation...

1. Take a branch from the Root.
2. Modify a file in the root (in changeset 1).
3. Modify the same file in the branch (in changeset 2).
4. Merge the change from the root into the branch (in changeset 3) by discarding the change in branch. So now the file in the branch contains a copy of the code from changeset 1.
5. Now you want to merge from the branch into the main and you'd expect to get the changes from changeset 3 back into the root. Here's the bad part...

instead of merging changeset 3 into the root (because changeset 3 is the most current changeset), TFS merges changeset 2. According to Microsoft, this behaviour is by design because the devs at Microsoft assume that your merge back to the root was done to rollback the previous merge from the root (doh!). TFS thinks that it should use changeset 2 instead of changeset 3 because the files were never actually merged, but overwritten. Microsoft is working on a hotfix, so if you stumble across this issue, contact Microsoft and request the fix.

Thanks Dan. Both for the original report and the later clarification.

Ta.
Steve Porter

A few weeks ago I stumbled upon a blog post that announced that IESC Geekcorp was looking for volunteers to travel to Lebanon to provide Team System training. I immediately thought, 'What a great opportunity', so I submitted my particulars and within a few days they gave me a call and said that they were interested in having me participate. After a few weeks of ironing out the details, the final few arrangements have been made and my participation has now been confirmed.

I'm scheduled to be in Beirut from June 9th, 2007 until June 23rd 2007. During that period, I'll be holding two three-day sessions on optimizing the software development lifecycle with Microsoft Visual Studio Team System in addition to meeting with individuals involved in the local software development community.

I'm really looking forward to this opportunity. Not only do I get to experience a whole new culture, but I can really put my money where my mouth is when it comes to helping out those in need. Lebanon has experienced a series of awful events over the last couple of decades and it's great that instead of just sitting on the sidelines and talking about what a bad situation it is, I can do something that might contribute to Lebanon re-establishing itself as the commercial centre of the Middle East.

If anyone has any suggestions about how I should spend my free time while I'm there (all work and no play makes Jack a dull boy), please drop me a note.

Ta.
Steve Porter

I just read an interesting post on Ryan Milligan's blog regarding the proper way to structure your code to correctly convey its intent to the reader.

Whenever I see this sort of code I think, is this a good case for refactoring into objects? Now, for his specific example, encapsulating these behaviours into objects may be overkill. However if you have a base set of behaviours and you find a special case, that screams out for a parent object and an inherited child where you override the base where required for your special case.

For those of you who haven't read Martin Fowler's book on refactoring or visited his site, I highly recommend you spend some time getting familiar with the techniques he describes.

One of the goals of refactoring is to make the code simpler (which isn't always easy). Simpler code is easier to maintain. Always remember that source code has two readers: the compiler and the coder. Both audiences are important. As Ryan points out, having your source code convey its intention to the coder reading it is important. The compiler won't really care how the code is structured as long as the results are the same, so why not make the code easier to read?

For all those hotshot coders out there who strive to produce tight code ("I can write that method in one line"), just remember that someone else may have to look at the code later and determine what the heck you were trying to do. Sure, you saved yourself a few key strokes, but your logic may be so obtuse that it requires a few lines of comments to explain just what the heck you're doing. And... who knows what the compiler is going to do with your wonderful code. Modern compilers are pretty good at optimizing code, so why not just keep it simple and let the compiler work out the details. The coder who has to maintain your code will thank you (and that coder may be you!).

Ta.
Steve Porter

I recently spent a week at a client’s site helping them implement Team Foundation Server into their development environment. In the end, everything was good, but the experience wasn’t as smooth as I would have liked. My experience with installing and configuring TFS has been almost universally positive, but this client’s environment proved to be challenging.

We met our first issue during the actual installation of TFS. I encountered error 28925 (Calling the Team Foundation Server ServerStatus Web service failed). After a little bit of troubleshooting (huge thanks to my client’s head of network infrastructure) we traced the issue down to the company’s proxy rules. The company has an enforced policy that pushes down the proxy settings and the installation process was having difficulty resolving its own name because the account we were using for the setup (TFSSetup) couldn’t authenticate against the proxy. We could have addressed the issue by granting the TFSSetup account rights to proxy server, but instead we just temporally disabled the proxy by clearing the entry from the registry.

Once we finished the installation, our troubles persisted. When we tried to register the newly installed team foundation server with the team explorer, we couldn’t successfully add the server by using the server name, but we could successfully add the server if we used the IP address. And I use the term “successfully” loosely here because once the server was added to Team Explorer and a team project was added, both the Documents folder and the Reports folders showed large unfriendly red x’s beside the folders. To make things more confusing, we didn't experience this behaviour if we were logged directly onto the Team Foundation Server.

Again, the proxy was the culprit here. Thanks to a post from Buck Hodges, we were able to get the environment correctly configured by following his instructions and adding the BypassProxyOnLocal string value to the registry under the key, HKEY_CURRENT_USER\Software\Microsoft\VisualStudio
\8.0\TeamFoundation\RequestSettings (which you will probably have to add yourself) and then setting its value to true. Once this was done on the all of the client machines, all was fine.

Ta.
Steve Porter

One of the things that I really love about my Mac is its ability to perform so many actions purely though keyboard shortcuts. Between using the built-in shortcuts and Quicksilver, I rarely have to use the mouse.

I’ve always thought of myself as a fairly proficient computer user, but I find that the more I use the keyboard and the less I rely on a pointing device, the more productive I become. The time I spend learning and practicing new ways of harnessing the power of keyboard shortcuts is always time well spent and ends up paying for itself

With this in mind, I’d like to direct you to this post in Ryan Milligan’s blog. Ryan is one of the best programmers I’ve had the pleasure to work beside and he is able to work the Visual Studio IDE like a concert pianist plays a baby grand. I can guarantee you that if master even a small subset of the commands listed in his blog, you will see measurable gains in your productivity. I’ve watched Ryan in action and I’m a believer.

Ta.
Steve Porter

An early beta of this tool was recently dropped to CodePlex. The purpose of the tool is to allow organizations to create tools that can be used to synchronize Team System work items and source code with other third party tools that have similar features to Team System.

One of the major challenges that an organization that wants to implement Visual Studio Team System faces, is that they may already have a major investment in another tool. The main issue I see is companies may already have an issues/bug tracking tool. Because of this, they feel that they can’t use Team System’s built-in work items and its excellent source control features. Up until now, all I could recommend to these organizations is that they consider performing a bit of double entry, where the primary identifier/key/ID from their existing issue tracking system be entered as a field into a new Team System work item. Doing this allows a level of traceability between the issue/bug in their legacy tracking system and the new work item in Team System.

Microsoft understands that this sort of manual double entry is a major impediment to Team System adoption (and the selling of Team System licenses ☺ ), so they’ve created this tool to assist in the migration and synchronization of data from an existing system into Team Foundation Server. Their eventual goal is to release migration/synchronization tools for all of the major vendors (Mercury, Borland), but by releasing this tool into the community, they’re hoping that companies who are using a home grown system might consider writing their own migration tool and eventually move entirely to Team System.

So if your organization is holding back from investigating Team System because you’re concerned about losing your investment in your current development management systems, have a look at what the migration/synchronization tool has to offer.

Ta.
Steve Porter

Brian Keller’s blog details the steps required to get Team Foundation Server to play nice with Windows SharePoint Services 3.0. For those who haven’t had an introduction to WSS 3.0 yet, you need to get on the bandwagon and quick.

Microsoft has seriously revamped this platform and a lot of organizations are planning to heavily leverage this tool in their organization to allow them to simply and quickly create web application like tools without having to write a whole bunch of code. Web developers who ignore this tool do so at their own risk. They may find that a lot of what they code by hand will be replaced by what this service provides right out of the box.

Imaginet has been spending a lot of time and effort getting ahead of the curve on this latest offering from Microsoft, so if your organization is looking for guidance, drop us a line.

Ta.
Steve Porter

I just finished reading an interesting article on what's plaguing the IT industry and can't help but think, "My, this sounds familiar". This is exactly the sort of environment that I see as I travel from company to company. It's not yet the norm, but the trend is obviously heading in that direction. That's really sad.

But it does motivate me to change things in my little corner of the world. We all really need to start looking around us and say, "How can we use technology to make things work better around here". Because at the end of the day, this is really what it's all about.

I'm not normally one to drink the Kool-Aid, but I really believe that Team System can help get some of the day to day drudgery out of the way and allow teams to focus on what's important.

Ta.
Steve Porter

One of the less fun administrative tasks with Team Foundation Server is the task of moving a work item from one team project to another. It's a manual task where you drag them from one project to another. Not to bad for a smaller project, but for a larger project with thousand of work items, not so good.

Fortunately, Eric Lee has created a tool that will assist with this task.

You can read about the tool here.

Thanks Eric.

Happy moving everyone.

Ta.
Steve Porter

One of the features that I love about Visual Studio Team System is the rich eventing model. Microsoft opened up this feature to allow developers to extend the built-in alerts and to roll their own event alerts, but it's not a trivial task.

Jeff Atwood at Vertigo Software has just posted a new tool to CodePlex that makes this process a little easier. You can find some additional information about the tool on his blog. I'm looking forward to giving it a test run.

Ta.
Steve Porter

I've been tagged (thanks Mike).

1. I'm a big fan of DC comics and role playing games (Dungeon and Dragons specifically) and I have been since I was young. Toss in my asthma and love of computers and you have the full geek package. And yes, I was beaten up a lot in school.

2. I lost two of my front teeth during a car accident that occurred while driving on a slippery road and not wearing a seat belt (dumb, dumb, dumb). I've had a slight lisp ever since (and it worsens the quicker I talk).

3. My first real job was that of a letter carrier (in Winnipeg... in the winter, yeah I know, I'm a sucker for punishment). I actually lost the job because I missed too many days of work. Losing the job turned out to be the best thing that ever happen to me since it eventually forced me to go back to school and pursue a career in software development.

4. I secretly want to learn how to play the tin whistle. I've taken some lessons and I can play a handful of songs, but I need to practice a lot more. Maybe when I'm retired I'll find the time.

5. I'm adopted and I very recently reunited with my birth father (who's just great and has a great family) and hope to have a reunion with my birth mother in the near future.

I'm tagging Robert Regnier, Ryan Milligan, David Maynard, James Struthers and Deborah Zanke. None of which have a blog. Maybe this will be the reason they start one.

Ta.
Steve Porter

Found an excellent post on Keith Elder's site that does a great job of describing how to structure your source files to take advantage of VSTS's source control features along with the built in automated build features.

At Imaginet, we've been following these patterns for awhile now, but Keith does a great job of bringing all of the best practices together.

Ta.
Steve Porter