I'm pleased to announce that I will again be speaking that this year's Microsoft Tech•Days in Winnipeg. Last year's event was jam-packed with great topics and excellent speakers and this year is looking to be more of the same.

I'll be presenting on a topic that I am very passionate about.

Day Two, Session 4: Database Change Management with Team System
If you develop database enabled applications on top of SQL Server, you owe it to yourself to considering doing it better with Visual Studio Team System. In this session, you’ll learn about changes to how the product works under the covers and what that means to you. Then, you’ll learn how to use the product to design, build, and deploy your databases to development, test, and production environments -- all with purpose and method instead of the more traditional madness that can be found in many shops in the wild.

Anyone who has heard me talk about Visual Studio Team System 2008 Database Edition (aka DataDude), knows that I'm enthusiastabout how this tool can make the arduous task of managing your database artifacts as easy as managing your .Net code.

I'm also happy to announce that I'll be joined by a large contingent of other Imaginet staff. In the Developer Fundamentals and Best Practices track alone, Imaginet's amazing roster of staff will be responsible for 75% of the topics.

Day One, Session 1: Tips and Tricks for Visual Studio
Jeremy Wiebe

Day One, Session 4: A Strategic Comparison of Data Access Technologies from Microsoft
Dave Harris

Day Two, Session 1: Practical Web Testing
Rob Regnier and Tyler Doerksen

Day Two, Session 2: Better Software Change and Configuration Management Using TFS
Aaron Kowall

Day Two, Session 3: Metrics That Matter: Using Team System for Process Improvement
Joel Semeniuk

Day Two, Session 4: Database Change Management with Team System
me, Steve Porter

Now that's what I call great coverage. In addition to this track, Mike Diehl will again be presenting on SQL Server. I never miss an opportunity to hear Mike speak and you shouldn't either.

So I hope you can join me December 15th and 16th. It should be a great experience.

Ta.
Steve Porter

Ta.
Steve Porter

I just finished an engagement with a client where one of my tasks was to help them move from their existing project management tool to TFS. During the roll-out, I was encountering a bit of resistance that was driven by their staff's level of comfort with the current tool compared to what they were seeing in TFS. One of the items they liked about their current tool is that it would auto-generate nifty graphs in Excel that they would hand off to their project sponsor each week. The purpose of the graphs was to show, from a very high level, progress of their work for a particular release.

I showed them the built-in reports that come with TFS and their response basically was, "that's cool, but I want this..." and pointed to their existing Excel reports. To overcome their resistance, I decided that I had to show them how easy it was to get the exact same report using TFS (emphasis on easy).

Step 1 - Create a query that filters based on the work item type field and displayed the state field.

Step 2 - Open the query in Excel.

Step 3 - For each state, create a cell that used the CountIf formula to count the number of occurrences for each state; =COUNTIF(B3:B2500,"Proposed").

Step 4 - Highlighted the formula cells and insert a column chart.

Step 5 - Click Refresh to show that the report gets recalculated with live data.

Done!

There are definitely other ways to do this (SQL reporting services, Excel pivot tables...), but this took me all of five minutes and met my customer's requirement.

Ta.
Steve Porter

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

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

Some of the items covered...

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

Ta.
Steve Porter

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

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

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

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

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

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

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

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

Ta.
Steve Porter

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

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 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

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

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

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

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

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

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.

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

Hope to see you there.

Ta.
Steve Porter

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

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

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

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

Ta
Steve Porter

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

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 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

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

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?

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

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

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

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

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

Ta.
Steve Porter

Ta.
Steve Porter

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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