I am really, really liking the shell integration features that can with this release. 

So convenient to be able to go to a directory, right click and check files in our out of the system.

Great job guys!

Tuesday, November 25, 2008 9:32:42 AM (Pacific Standard Time, UTC-08:00)         Comments [0]   VSTS

Recently setup a new TFS2008 installation out in my colocation and had issues with the report and document nodes in my TFS projects not coming alive.  I had put the correct routes into my ISA Server but those other links weren’t working.

I had forgotten to update the wss and report servers names in the registration data on the application tier.

To get the registration data do a:

TFSReg /EXPORT reg.xml APPTIERSERVERNAME

Change the following values to the FQDN of your application tier:

ATMachineName

ReportsService

BaseReportsUrl

WssAdminService

BaseSiteUrl

There are a few settings in the registry also:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\TeamFoundation\ReportServer\80\Sites

Has BaseReportsService and BaseSiteUrl that also needs to be changed.

Finally clear your cache at (for vista):

c:\users\@username@\appdata\local\microsoft\team foundation\2.0

and delete the cache folder in that location.

Found a great article here somewhat after the fact: http://bloggingabout.net/blogs/mglaser/archive/2007/01/31/hosting-team-foundation-server-on-a-fully-qualified-domain-name-fqdn.aspx

Friday, March 14, 2008 10:01:05 PM (Pacific Standard Time, UTC-08:00)         Comments [0]   VSTS

I had an issue with Outlook 2003 that after installing Visual Studio Team Suite RTM & Team Foundation Client almost everytime I tried to start outlook it would attempt to run visual studio setup.  It would prompt for a disk, run for awhile and then let me use Outlook.  I thought I was alone until Walt Ritscher mentioned having similar problems. 

I tried everything just short of paving my laptop to get rid of this including uninstall reinstall of Office 2003, Visual Studio 2005, etc.

Finally I found a forum post that mentioned re-registering a Windows Installer dll.

In short: regsvr32 "C:\Program Files\Common Files\Microsoft Shared\MSI Tools\mergemod.dll"

More information is in this MSKB article: http://support.microsoft.com/kb/329214/EN-US/

Thursday, December 22, 2005 10:11:55 AM (Pacific Standard Time, UTC-08:00)         Comments [0]   VSTS

I was interested in exposing our Team Foundation Server Beta 3 Refresh install out over the internet so I could use it from client sites, etc.

It turned out to be more effort than I had hoped.  Figured I would document it for the next time I have to do it.  These instructions are for a dual server install.  A single server install should be a little bit simpler.

Start off by creating two public dns names:

tfs.domain.com

and

tfsreports.domain.com

Publish a web server pointing at your application tier using the tfs.domain.com domain name.  Set the listener up to listen on Port 8080 and authentication should be integrated only.  Don't forget to go back into the properties for the policy and make sure the bridging options are set to forward on Port 8080.  It defaults to Port 80 which hung me up for awhile.  This policy is for the web services.

Publish a web server pointing at your application tier using the tfs.domain.com domain name again.  This time set the listener up on the normal Port 80 with authentication set to integrated only.  This policy is for Windows Sharepoint Services.

Publish a web server pointing at your application tier using the tfs.domain.com domain name again.  This time set the listener up on Port 17012 and authentication should be integrated only.  Don't forget to go back the properties for the policy and make sure the bridging options are set to forward on Port 17012.  NOTE: 17012 may not be the correct port for your installation.  Replace it with whatever port Sharepoint Central Administration is configured to run on.

Publish a web server pointing at your data tier using the tfsreports.domain.com domain name. If you want you can limit the path to /Reports/* and /ReportServer/*.  My understanding is that they are moving reporting services to the application tier for RTM so this step will go away.  Listener is on Port 80 with integrated authentication.

That's it for the ISA Server setup.  The problem is that the configuration database for TFS still has the internal machine names specified for accessing WSS and Reporting Services.  This can be fixed by creating a file containing:

    Reports
    Change
   
     
        ReportsService
        http://tfsreports.domain.com/ReportServer/ReportService.asmx
     
     
        BaseReportsUrl
        http://tfsreports.domain.com/Reports
     
  
        DataSourceServer
        http://tfsreports.domain.com/ReportServer
     
   


    Wss
    Change
   
     
        BaseServerUrl
        http://tfs.domain.com
     
     
        BaseSiteUrl
        http://tfs.domain.com/sites
     
     
        BaseSiteUnc
        \\colfax\sites
     
  
        WssAdminService
        http://tfs.domain.com:17012/_vti_adm/admin.asmx
          
   
 

Replace ATNAME with the name of your application tier server.

Save this file as c:\Program Files\Microsoft Visual Studio 2005 Team Foundation Server\Tools\myreg.xml

Open a command prompt in this location and use TfsReg to import the registration information above like this:

TfsReg myreg.xml dtname

Of course replace dtname with the name of your data tier server.

That's it.  That got it running over the internet for me.

Tuesday, December 20, 2005 4:22:36 PM (Pacific Standard Time, UTC-08:00)         Comments [1]   VSTS

When I first started out with VSTS I created a nightly build project. Since I was just setting up my solution I did not yet have any tests to run.

Team Build unfortunately is a one way interface.  Once you setup the build the only editing experience you get in MSBuild!

So the trick to adding tests to a build without them is as follows.  Look for:

    <TestingFlag>false</TestingFlag>
    <!--  TEST ARGUMENTS
          If the TestingFlag is set to true then the following is relevant
          Metadatatest file path - mandatory
          Testlist name, a test list which is a part of the selected metadata file - mandatory
          Runconfiguration file path - optional, defaults to the active run configuration in the metadatafilename
        
    -->
    <TestingArgs> </TestingArgs>

Change the TestingFlag to true and point it at the vsmdi file in your solution which contains information about which tests to run.  Like this:

    <TestingFlag>true</TestingFlag>
    <!--  TEST ARGUMENTS
          If the TestingFlag is set to true then the following is relevant
          Metadatatest file path - mandatory
          Testlist name, a test list which is a part of the selected metadata file - mandatory
          Runconfiguration file path - optional, defaults to the active run configuration in the metadatafilename
        
    -->
    <TestingArgs>/testmetadata:$(SolutionRoot)\VergentSoftware.SeattleTraffic.vsmdi</TestingArgs>

Thursday, May 19, 2005 8:35:23 AM (Pacific Standard Time, UTC-08:00)         Comments [0]   VSTS