Ta. Steve Porter

Kathryn Elliott, a member of the Team System documentation team, is looking for feedback on the customization process.

One of the things I love about Team System is the amount of customization that is supports, but I'll admit that it's not always the easiest beast to work with.

Here are some items from my wish list:

1. Documentation on how to restrict access to adding or editing a work item type
2. Documentation on how to restrict access to a field within a work items
3. Documentation on how to restrict what you can enter into a field
(do you see a trend?)
4. Documentation on how to restrict state transitions
5. One easy to search and access location that holds all the customization data

How does this list sound? Is it similar to what you're looking for?

Head over to her blog and add your suggestions.

Ta.
Steve Porter

If you're an MSDN subscriber, then you should head over to the download area (link) and get yourself a copy of Visual Studio 2010 Beta 1. Congratulations to all the folks on the development team for reaching this milestone. I'm looking forward to seeing the latest incarnation of all the various Team System features. I'm particularly interested in playing around with various migration scenarios to see what sort of work 2008 and 2005 shops are going to have to perform to get access to all of the 2010 goodness (like hierarchical work items, workflow driven builds, amazing branch and merge functionality).

For you non-MSDN subscribers, you'll be able to get access on Wednesday 10:00 am PST. Hope you can stand the wait.

Ta.
Steve Porter

You should take about 45 minutes to watch this video from TechEd where Joel Semeniuk, Stephen Forte and Chris Menegay talk about Agile development in the real world.

Some of the items covered...

• What Agile is (and isn't)
• Team System and Agile Development
• CMMI and Agile

Ta.
Steve Porter

This little beauty came up awhile ago and I just now found some time to blog about it.

I was on a project where one of my tasks was to keep the build up and running and for the most part it was a fairly painless tasks (no small thanks to the well oiled dev team). But one week-end, the build started to partially fail with a very cryptic message in the log file about the publishing failing. Unfortunately for me, the check-in that caused the breakage was a big one, so tracking down the issue took a lot of manual poking around until I stumbled upon the offending code.

It seems that the test publish mechanism doesn't like it when your test names are longer then 255 characters. Doh! The team included one developer who is a unit testing machine, and in his zeal, he had three tests that had more then 255 characters in the name. Here's a sample...

Should_move_to_PainManagementOptions_state_when_StepBackward_is_called_on_a_CarePlan
_with_nerve_root_low_back_pain_condition_segment_in_ReferralSelection_state_with_SpecialistGroup_of_
PainClinicReferralGroup_and_no_answer_value_for_PainManagementNextStepsProceed_question

Yes, quite the mouthful, but it describes exactly what he's testing, so all's good. Except it's too long.

Once all the offending tests were shortened, the build went back to behaving correct and just to be on the safe side, the developer wrote a unit test that checks the length of the test name for all the tests in the test assembly and the test fails if it locates any that are too long. This way, the build still only partially succeeds, but at least the error message in the build is helpful in figuring out the issue.

Here's the test he wrote (which we now include in all of our test projects).

 /// <summary>
 /// Summary description for UnitTestTests
 /// </summary>
 [TestClass]
 public class UnitTestTests
 {
     [TestMethod]
     public void Test_method_names_must_not_be_longer_than_255_characters()
     {
         var assembly = System.Reflection.Assembly.GetAssembly(typeof (UnitTestTests));
         var types = assembly.GetTypes();

         foreach (var type in types)
         {
             var member = type.GetMembers();
             foreach (var info in member)
             {
                 if (info.IsDefined(typeof(TestMethodAttribute), true))
                 {
                  Assert.IsTrue(info.Name.Length <= 255,
                      string.Format("Test Method name '{0}' is too long!", info.Name));
                 }
             }
         }
     }
 }

Shout out to Dave Harris for the unit test.

Ta.
Steve Porter

As a fairly recent Mac convert, I've been watching the Vista/Windows 7 saga with much interest. I love my mac, but I make my living on Windows (at least until Microsoft creates a OSX version of Visual Studio), so the sooner Microsoft can put the whole Vista thing behind them, the better.

I've been playing around with the new version for a few days now and I really like what I see. The whole UAC story is much improved (and when you're a developer/power user, this is a big deal) and the OS is much more responsive. It painlessly installed it on my Acer Aspire One net book and kicks Vista to the curb as far as performance goes.

Most importantly, Team Explorer seems to run fine, along with the Power tools and TFS Sidekicks. I'll have to use it a bit more to be sure, but as of now, I've replaced my main virtual environment with Windows 7 RC.

Ta.
Steve Porter

Brian Harry just released a high-level list of all VSTS 2010 features.

This is a major release for Team System and a lot of gaps in the original product will be filled once this version hits the streets. I hope companies that may have been sitting on the sideline waiting for this product to mature will take a serious look at what you get for your investment.

The testing changes are really a massive shift for this product and should move these features from "ya, that's neat" to "I want to go there".

Ta.
Steve Porter

One of the key TFS adoption road blocks that a lot of companies face is how do they integrate their existing application development infrastructure with Team Foundation Server and Team System. I've found a lot of companies willing to give TFS a try as far as source control, automated builds and work item tracking, but QA teams become really attached to their tools and are loath to give them up.

Well, the product team has been hard at work trying to address that issue and I'm happy to hear that they're making good progress on one of the more popular testing products, HP Quality Center. This is their second pre-realease, but it looks polished and ready to have it's tires kicked. You can read more about it on Brian Harry's blog and Jim Lamb's blog.

One interesting note,

     "The Connector itself is free. It does, however, require a TFS CAL and a QC CAL for the machine it's running on. In addition, everyone who views/edits data that's stored in TFS will need a TFS CAL."

I really wish Microsoft would come up with a better licensing scheme. This one item may kill any adoption by a larger organization. I applauded Microsoft when they removed the licensing restrictions for creating and viewing your own work items, but to better adoption, they really need to open up the entire work item repository to everyone in the organization without the nasty licensing overhead (both from a money and logistical perspective).

Ta.
Steve Porter

Conchango's task board is great, but a couple of the things that I think are missing compared to good old post-it notes are ease of use and visibility. It's really simple to move around post-it notes to change a work items status/iteration/area and you can put post-it notes up on a white board for all the team to see.

So here's what we do to get the best of both worlds. It's really simple to export work items to excel and then use this data as part of a Word mail merge. We merge the data to sheets of large labels (4" X 2" works well) and then put the labels on large coloured post-it notes (3M has good 2 7/8" X 4 7/8" colours notes for sale). We then use these post-its in our planning sessions and leave them up on the wall to help track our progress. There is obviously a bit of overhead creating and updating the labels and then transferring information back to team system based on changes to the post-it notes, but the work really is minimal and the additional visibility and ease of use make up for the extra work.

Ta.
Steve Porter

I was following Roy Osherove's post on unit testing Silverlight applications and notice some strange behaviour in Visual Studio that I thought I'd pass along.

It seem that when your solution contains a Silverlight Application Project, you can't access the code coverage tab in the Test Run Config dialog. As soon as you click on the Code Coverage list item, the Test Run Config dialog disappears. Poof, just like that. Not even a wave good-bye (how rude). Silverlight class libraries are fine. Actually better then fine in that the code coverage results work like a charm and show your percentages and the code highlighting feature that I just love displays as expected.

So, if you have a solution that contains both a Silverlight application and a Silverlight class library, you may have to temporarily remove the Application to set the code coverage information for your class library. Maybe if I have the time, I'll do a bit of fooling around to see if I can manually create the correct entries in the config file and get things working correctly...

Ta.
Steve Porter

Not only did I have an excellent week-end out at the lake with my family (I was able to try driving a snow mobile for the first time and we had a massive bonfire out on the ice), but when I returned home, sitting in my inbox was a congratulatory e-mail from Microsoft informing me that I've been awarded a Team System MVP for 2009!

What a massive honour and a huge responsibility. Look like 2009 is starting out to be a great year, let see if I can keep the momentum going.

Ta.
Steve Porter

I was tasked with getting our new Silverlight application building and deploying using Team Build. The application has been in pre-development stages for awhile now and the team was happy enough with their progress that they wanted to get the code into Team System. One of the requirements was that the application had to be secure, so SSL was a must, but our spiking developers were only testing on their local development environment, so no SSL. I knew that I was going to get hit with a few "it works on my machine" issues when I tried to deploy their existing code to our application server under SSL. This was one time when I wasn't happy about being right. To make matters even more challenging, the changes that I made had to be build specific, since I didn't want to force the developers to work with SSL on their local machines. Oh Joy!

First thing I did was to just get the application deploying and running using basic http. I encountered my first set of issues here. The team had followed the excellent post from Brad Abrams on how to configure the ASP.Net services in Silverlight. In the development environment, the WCF services for authentication, profile and role were running on the local machine and the team had hard coded the endpoint addresses in the ServiceReferences.ClientConfig. Obviously, this had to change. So my first step was to get my build to swap out the local urls for the urls on the server. The XmlUpdate task from MSBuild Community Tasks to the rescue. I just used this task to locate and change the 3 urls and this was all that was required to get the application working in our deployment environment. But still no SSL.

Here's what that ended up looking like...

<Target Name="UpdateServiceReferences" >

  <Message Text="Executing UpdateServiceReferences" />

  <ItemGroup>

    <ServiceReferences Include="$(SolutionRoot)\Source\WebApp\ServiceReferences.ClientConfig" />

  </ItemGroup>

  <Attrib Files="@(ServiceReferences)"

    ReadOnly="false"/>

  <XmlUpdate XmlFileName="%(ServiceReferences.FullPath)"

    XPath="//configuration/system.serviceModel/client/endpoint[@name='BasicHttpBinding_AuthenticationService']/@address"

    Value="http://webserver/webapp/Services/Application%20Services/AuthenticationService.svc" />

  <XmlUpdate XmlFileName="%(ServiceReferences.FullPath)"

    XPath="//configuration/system.serviceModel/client/endpoint[@name='BasicHttpBinding_ProfileService']/@address"

    Value="http://webserver/webapp/Services/Application%20Services/ProfileService.svc" />

  <XmlUpdate XmlFileName="%(ServiceReferences.FullPath)"

    XPath="//configuration/system.serviceModel/client/endpoint[@name='BasicHttpBinding_RoleService']/@address"

    Value="http://webserver/webapp/Services/Application%20Services/RoleService.svc" />

</Target>

Now that I had basic http working, I changed the web site to support ssl and then tried to connect. Well, not surprisingly, KaBoom as soon as the application tried to access the authentication service.

OK, the first fix was easy. I adjusted the code above to point at https and not http, hoping that would just fix it, but alas no...

To get it to work, I actually had to adjust the web.config to get SSL support for the asp.net WCF services. I followed the example here on the local copy of the web.config to see if that would fix the issue, but still no love.

I then noticed that in my ServiceReferences.ClientConfig, I had a line there that describes the security mode. Didn't I see the same line in the MSDN sample? So I did... So, in the ServiceReferences.ClientConfig, I changed the mode to Transport to match what I had done in the web.config, rebuilt and re-deployed the app and success! Unfortunately for me, the changes I made to both the ServiceReferences.ClientConfig and the web.config have to happen during the build, so I was back using XmlUpdate to get all the proper values swapped out. Here's what I ended up with...

<Target Name="UpdateServiceReferences" >

  <Message Text="Executing UpdateServiceReferences" />

  <ItemGroup>

    <ServiceReferences Include="$(SolutionRoot)\Source\SilverlightApp\ServiceReferences.ClientConfig" />

  </ItemGroup>

  <Attrib Files="@(ServiceReferences)"

    ReadOnly="false"/>

  <XmlUpdate XmlFileName="%(ServiceReferences.FullPath)"

    XPath="//configuration/system.serviceModel/client/endpoint[@name='BasicHttpBinding_AuthenticationService']/@address"

    Value="https://WebServer/WebApp/Services/Application%20Services/AuthenticationService.svc" />

  <XmlUpdate XmlFileName="%(ServiceReferences.FullPath)"

    XPath="//configuration/system.serviceModel/bindings/basicHttpBinding/binding[@name='BasicHttpBinding_AuthenticationService']/security/@mode"

    Value="Transport" />

  <XmlUpdate XmlFileName="%(ServiceReferences.FullPath)"

    XPath="//configuration/system.serviceModel/client/endpoint[@name='BasicHttpBinding_ProfileService']/@address"

    Value="https://WebServer/WebApp/Services/Application%20Services/ProfileService.svc" />

  <XmlUpdate XmlFileName="%(ServiceReferences.FullPath)"

    XPath="//configuration/system.serviceModel/bindings/basicHttpBinding/binding[@name='BasicHttpBinding_ProfileService']/security/@mode"

    Value="Transport" />

  <XmlUpdate XmlFileName="%(ServiceReferences.FullPath)"

    XPath="//configuration/system.serviceModel/client/endpoint[@name='BasicHttpBinding_RoleService']/@address"

    Value="https://WebServer/WebApp/Services/Application%20Services/RoleService.svc" />

  <XmlUpdate XmlFileName="%(ServiceReferences.FullPath)"

    XPath="//configuration/system.serviceModel/bindings/basicHttpBinding/binding[@name='BasicHttpBinding_RoleService']/security/@mode"

    Value="Transport" />

</Target>

<Target Name="UpdateWebConfig" >

  <Message Text="Executing UpdateWebConfig" />

  <ItemGroup>

    <WebConfig Include="$(SolutionRoot)\Source\WebApp\Web.Config" />

  </ItemGroup>

  <Attrib Files="@(WebConfig)"

    ReadOnly="false"/>

  <XmlUpdate XmlFileName="%(WebConfig.FullPath)"

    XPath="//configuration/system.serviceModel/services/service[@name='System.Web.ApplicationServices.AuthenticationService']/endpoint/@bindingConfiguration"

    Value="userHttps" />

  <XmlUpdate XmlFileName="%(WebConfig.FullPath)"

    XPath="//configuration/system.serviceModel/services/service[@name='System.Web.ApplicationServices.ProfileService']/endpoint/@bindingConfiguration"

    Value="userHttps" />

  <XmlUpdate XmlFileName="%(WebConfig.FullPath)"

    XPath="//configuration/system.serviceModel/services/service[@name='System.Web.ApplicationServices.RoleService']/endpoint/@bindingConfiguration"

    Value="userHttps" />

  <XmlUpdate XmlFileName="%(WebConfig.FullPath)"

    XPath="//configuration/system.serviceModel/bindings/basicHttpBinding/binding/security/@mode"

    Value="Transport" />

  <XmlUpdate XmlFileName="%(WebConfig.FullPath)"

    XPath="//configuration/system.serviceModel/bindings/basicHttpBinding/binding/@name"

    Value="userHttps" />

  <XmlUpdate XmlFileName="%(WebConfig.FullPath)"

    XPath="//configuration/system.web.extensions/scripting/webServices/authenticationService/@requireSSL"

    Value="true" />

</Target>

<Target Name="BeforeCompile" DependsOnTargets="UpdateServiceReferences;UpdateWebConfig" />

I didn't show the target that actually deploys the site, but if you want to see what that looks like, drop me a comment and I'll pass that along.

Good Luck!

Ta.
Steve Porter

As with previous releases of the TFS Power Tools, you have to uninstall the previous version before you can install the new version. This hasn't been an issue for me until this latest release. The October 08 release moves from a per user install to an all user install. If the machine you're installing on only has one user who has installed a previous version of the power tools, then you're golden. But... if a different account has installed different versions onto the machine, you may have trouble.

One quick caveat, this issue with the power tools occurred on a machine with Windows 2003 installed, so if you have another OS, YMMV.

This was the issue I encountered on one of my sandbox VPCs that I use for demos. I uninstalled the current version, but when I went to install the October release, I was informed that there were other installs on the machine that I had to uninstall first before I could continue. The installation package was nice enough to tell me which user account was the offending culprit, so I thought I could just log in as that account, uninstall the previous version and Bob's your Uncle...

Well, Bob is not my Uncle, bastard!

When I attempted to uninstall the previous version on the second account, the uninstalltion process failed (epic). It complained about missing files, which makes sense because I'd already uninstalled the files under the other account. Doh!

Don't get me started on uninstall processes that fail because it can't find a file to remove. Helloooo, I'm trying to remove these files in the first place. Move along, nothing to see here...

There is documentation on how to fix this located on the power tools download site (in Word format, grumble. What's wrong with PDFs people!) but it doesn't mention my issue, so I was left to troubleshoot the issue on my own.

Here's how I fixed it.

1. Obtain the original install package for the version that your're trying to remove. That's was actually harder then it sounds. My Google-fu must be weak, because I couldn't find any links to download the previous versions. Fortunately for me, I had them archived.
2. Go to the Add/Remove Program control panel utility, locate the offending power tools entry and Click Change. You will then when prompted for what maintenance action you'd like to perform, for this action, select Repair. The maintenance package will then prompt you for the location of the install package, which you located in step one.
3. Once it's finished repairing your installation, you can then use Add/Remove Program to uninstall Power Tools. It should work successfully now.
4. Now that you've removed all the previous versions, you should be able to successfully install the October release.

Bob is now your uncle! Lets hear it for Bob.

I know what you may be thinking... "Great, you had all of the previous Power Tool installation packages archived, good for you. What do you want, a medal? How does that help me?" Well, here's what I'll do. I've placed my archived copies up on my web site and I'll leave them there until someone tells me that Microsoft has made them available. No, please, no need to thank me...

• December 2007
• March 2008
• July 2008

I've virus scanned all of these files, but I take no responsibility for their contents. Sorry to have to make that disclaimer, but the world has too many lawyers with nothing to do now that the number of Wall Street takes-overs have declined.

Leave me a comment if you encountered this same issue. Maybe you solved it differently?

Ta.
Steve Porter

The October 2008 release is now available and it looks like the TFS team at Microsoft has done it again. There are some amazing new features here that should make working with TFS even easier. You can get all of the details here and here, but the pieces that excite me the most are the workspace templates, custom component support and the windows shell integration (which doesn't seem to work on my XP box :( Maybe it's a Vista only thing).

Give it a try and let me know what you think of the new features.

Ta.
Steve Porter

Buck Hodges has a great blog post on setting up TFS to use TSWA links, but there was one additional piece of information that I couldn't find anywhere, so I thought I'd post it on my blog.

Most of the examples I could find for how to configure the system detailed how to adjust the server's xsl document but they all assumed that the web access power tool was installed on the same server. To get the links generating correctly, I had to slightly adjust the recommended change to WorkItemChangedEvent.xsl.

I changed the line from:

<xsl:attribute name="href"> <xsl:value-of select="DisplayUrl" /> </xsl:attribute>

to:

<xsl:attribute name="href">
    http://YOURSERVER:YOURPORT/wi.aspx?id=<xsl:value-of select="substring-after(DisplayUrl,'artifactMoniker=')" />
</xsl:attribute>

One additional gotcha is that this change won't take effect until after you recycle IIS where the Team Foundation Server's app tier is hosted.

Leave me a comment if you like the notification integration with TSWA.

Ta.
Steve Porter

This week I accidently brought our production Team Foundation Server to a grinding halt and I thought that I'd share my experience so that no one else out there has to deal with the same issue I did.

I was planning on installing the new service pack for TFS over the up-coming week-end, and in preparation for that bit of maintenance, I decided to install the Visual Studio 2008 service pack on the application tier. I make it a habit to install the Team Explorer on my app tier so that I can create team projects locally, and because of this, I knew that I had to install the Visual Studio service pack before I installed the Team Foundation Server service pack.

My assumption was that these two service packs were mostly unrelated (one being for the client and the other being for the server) but that didn't prove to be the case at all.

Initially, the Visual Studio 2008 service pack installation went well. It didn't even require a reboot, so I was able to apply it during business hours. It wasn't until over 24 hours passed that I discovered that the two service packs were related.

I received a message from our development team that our Team Server was unreachable. I was able to log onto the server, but a quick check of the event log showed that I was having severe server issues with all of the various web services. The error message that was placed in the event log was cryptic (TF53010: The following error has occurred in a Team Foundation component or extension: and then a large error dump) but I was able to resolve the entire issue by installing Team Foundation Server SP1.

All's well that end's well I guess, but there was definitely a period of time when I was not a happy camper.

If this requirement is explained in the Visual Studio SP1 documentation then I guess that I should have RTFM before I installed the service pack. If it's not documented, it should be.

Drop me a comment ant let me know how has your maintenance has gone?

Ta.
Steve Porter

If you're a user of Conchango's excellent Scrum for Team System Process Template, then you'll be happy to hear that a new version is due out soon.

If you're currently using the scrum methodology in your development process and you have access to Team System, I highly recommend that you check out this template. It does an excellent job of automating a lot of the tracking tasks and provides a great framework for managing your scrum projects.

In addition to the template, you should also investigate their task board application. This client application provides a very user-friendly UI where you can create and update your backlog items. The application manages all the links between product backlog work items and sprint backlog work items and helps track the state as they move from unassigned, to assigned, to ready for test, to done.

If you'ld like to share your experiences using the current version of this template, please leave me a comment.

Ta.
Steve Porter

The latest edition of the Team Foundation Power Tools added a new command called Scorch that I just love.

I do all of my Visual Studio work on a virtual machine and leverage snapshots and undo disks to keep my environment as clean as possible. One major downside for this is that my local source is often out of sync with TFS. For example, I'll perform a Get Latest each morning and refresh my local source and in the process pick up a couple of new file versions. All Good. Now, at the end of the day, I'll shelve my local changes up to the server (where they're safe) and the I'll shut down my virtual machine and not commit any of the changes to the virtual machine's drive. So far so good. Next morning I come in and start my virtual machine. It reverts to it's original state (since I didn't commit any of yesterday's changes) so my OS stays nice and clean, but now when I perform a Get Latest, the new file versions that I picked up yesterday won't be transfered to my local drive since the server already thinks that I picked up those changes yesterday. All Bad.

I can perform a Get Specific, but that usually means I have to get all the files, not just the ones that I'm missing. Again, All Bad.

This is where Scorch comes in. It will perform a diff on my local drive and just get the files that are different. Back to the All Good column.

Does anyone else use a virtual environment for Visual Studio development with Team System? How about sharing some tips that have made your life easier.

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>System.AssignedTo=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