Team Build's 'Get' always writes files with the current date

We use Team Build for all of our builds including the packaging of our Static Content application. When Team Build does a 'Get' of Sources it writes the files with the creation/modify date of the current build time. For example if I checked in a file (e.g. Mac.jpeg) yesterday (5/14/08), but didn't run a Team Build until today, the file date would be today (5/15/08). For most things this is not an issue, but for Static Content it is.

The reason having the current date/time on Static Content is an issue is because of the way the browser caches things. When a request is made to our site(s), the browser will see that we have images (e.g. Mac.jpeg). Before grabbing the image from the web server the browser will check its local cache. If the image in the local cache has the same modify date as the image on the web server, the image is not requested, thus improving performance. However, if the local cached version of the image file is older than the web server's version, the new image is sent to the requested user.

The issue is, because Team Build always writes the files with the current date (e.g. 5/15/08), when we deploy them to the Static Content servers they all look like updated image files. This is bad as it invalidates ever user's cache and thus slows down our application as every image is sent to the user.

I've read a bunch of things on this and from what I've heard, the TFS Product Team might be looking into a fix for this. I've dropped our local Microsoft rep a note asking him if he had any details about that. I've also found this post from Cory Foy which looks like a custom task we might be able to write in order to get the behavior we need. If I get any word back from my Microsoft contact, I'll let everyone know. In the mean time, we are looking into Cory Foy's approach.

I'm also going to drop a note to the good folks over at Teamprise to get their input. We're using their Ant interfaces to TFS for some of our non-Microsoft builds and thus could have a similar issue.

Bug in the TFS 2008 Uninstall on Standby App Tier

A colleague of mine, who has taken over many of my former TFS duties, ran into an interesting problem today. For reasons I won't get into, we were trying to uninstall TFS 2008 from our Standby App Tier.

The error we ran into was as follows. We found this error in the VSMsiLog which is created for installs and uninstalls.

05/08/08 11:35:14 DDSet_Status: --- STATUS: Found Reports.ReportsService=http://tfs.mycompany.com/ReportServer/ReportService.asmx
05/08/08 11:35:14 DDSet_Status: --- STATUS: Writing VSTF_RS_SERVER=tfs.mycompany.com into C:\Documents and Settings\appwesttfnqasetup\Local Settings\Temp\TfsCurrentConfig.ini section Config
05/08/08 11:35:16 DDSet_Error: *** ERROR: Failed to call WMI on the RS server. The most likely cause is that the firewall is blocking WMI calls or that the RS server is not reachable: The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)
05/08/08 11:35:16 DDSet_Status: Process exited with exit code: 16

05/08/08 11:35:16 DDSet_Error: GetCurrentTfsProperties failed with exit code: 16
MSI (s) (B4!A4) [11:35:22:083]: Product: Microsoft Visual Studio 2008 Team Foundation Server - ENU -- There is a problem with this Windows Installer package. Please refer to the setup log for more information.

You'll notice that the uninstall was looking for the value ReportService which is found in the TfsIntegration database's tbl_service_interface table. The value in that table is a FQDN which we use because we have Primary and Standby App Tiers. As defined in the TFS documentation, only one is active at a time.

The Bug in the uninstall is, if you are setup behind a FQDN the value of ReportService will be the FQDN (e.g. tfs.mycompany.com) instead of the value of the Standby App Tier, which is what you're trying to uninstall.

A quick Google search led me to this blog post by Nick Berardi on his Coder Journal. He ran into a similar issue during an upgrade. He got around the error by changing the ReportService value to match his App Tier.

While I never recommend messing with the TFS databases, being we're in a QA environment I gave Nick's idea a shot. Sure enough, the uninstall finished successfully. I then changed the value back to our FQDN so the Primary App Tier could be functional.

I'm not sure why the uninstall would need these values for Reporting Services. From what the uninstall documentation says, you must uninstall Reporting Services (and Share Point) as an independent step? Anyway, again while I never recommend manually changing values in the TFS databases, we ended up needing to as to get around the uninstall issue.

Deployment to IIS 7.0 using Power Shell

Yes, I'm still here. Sorry for not writing anything lately on TFS. I've been in one of those two week Agile (with a capital A) "Iterations" which is when we get all the work done.

I don't really have anything important to share right now on our TFS adoption. Everything is going pretty good. Knock on wood!

While not really related to TFS though, I've fallen in love with Power Shell 1.0. Everyday I find another problem to solve with "commandlets" and all the great things a full featured shell offers. Along with the AppCMD command which ships with IIS 7.0, we're using Power Shell scripts to drive our deployment mechanism. Here is a simple example of what our scripts look like. It's actually working very well for us and far less overhead than creating an msi or Install Shield package.

You'll notice that we take the nuke and pave approach to deployment. That is, we check to see if the application directory is there, and if it is, we purge it. Then we copy over the new application version's code.


#Always get the script root. Per Microsoft's recommendation, each script should know their respected script root.
$SCRIPT_ROOT = Split-Path (Resolve-Path $myInvocation.MyCommand.Path)

#check to see if these values are already set. If not, set them to defalts.
if ($ENV_SITE_NAME -eq $null) {sv ENV_SITE_NAME -value Website}
if ($ENV_APPPOOL_NAME -eq $null) {sv ENV_APPPOOL_NAME -value WebsiteAppPool}
if ($ENV_PORT_NUMBER -eq $null) {sv ENV_PORT_NUMBER -Value "8080"}

sv APPCMD -value $env:systemroot\system32\inetsrv\AppCmd.exe
sv SITE_INSTALL_PATH -value "D:\Web Sites\$ENV_SITE_NAME"
sv APP_SERVICES -Value "aspnet_state", "W3SVC"
# ***************************************************
# Step 1)
# Clean up old install.
Invoke-Expression "$APPCMD delete site $ENV_SITE_NAME"
Invoke-Expression "$APPCMD delete apppool $ENV_APPPOOL_NAME"
if (Test-Path $SITE_INSTALL_PATH) {rmdir -Recurse -Force $SITE_INSTALL_PATH}
# ***************************************************# Step 2)
# Make dirs
New-Item $SITE_INSTALL_PATH -type directory
# ***************************************************
# Step 3)
# Create the AppPool for this site
Invoke-Expression "$APPCMD add apppool /name:$ENV_APPPOOL_NAME"
Invoke-Expression "$APPCMD set apppool /apppool.name:$ENV_APPPOOL_NAME /processModel.identityType:NetworkService"
# ***************************************************
# Step 4)
# This will add the site on port 81. This does not create an App or Virtual Director by default. *****
Invoke-Expression "$APPCMD add site /name:$ENV_SITE_NAME /bindings:`"http/*:${ENV_PORT_NUMBER}:`""
# ***************************************************
# Step 5)
# Craete App with the physical path and set the Apppool we need ******
Invoke-Expression "$APPCMD add app /site.name:$ENV_SITE_NAME /path:/ /physicalPath:`"$SITE_INSTALL_PATH`" /applicationPool:$ENV_APPPOOL_NAME"
# ***************************************************
# Step 6)
# Copy over files recursively (/E and /I), overwrite read only files (/R), surpress comfirmation (/Y), quietly *****
echo "Copy Files to WebSite"
xcopy $SCRIPT_ROOT\Website $SITE_INSTALL_PATH /E /I /R /Y /Q
# ***************************************************
# Step 7)
# Make sure any needed services are started before finishing and spits out their status.
Invoke-Expression "$APPCMD start apppool /apppool.name:$ENV_APPPOOL_NAME"
Invoke-Expression "$APPCMD start site /site.name:$ENV_SITE_NAME"
$APP_SERVICES Start-Service
$APP_SERVICES Get-Service
# ***************************************************
# Step 8)
# Make sure we didn't get any errors at deployment.
if ($error.count -lt 1)
{
Write-Output "" "Deployment Successful!" ""

}
else
{
Write-Output "" "Deployment Failed!" ""
$error
Write-Output ""
}

Follow-up on our Restore Attempt(s)

Two weeks ago today I left the building frustrated with Microsoft because of poor documentation. You can see my rant here.

I'm still a bit miffed that the "How to restore..." document was (and still is as of this writing) wrong, but I'm feeling better that they have graciously apologized to me. And the fact that with the help of Support, we're up and running in the restored test environment. Being I'll most likely forget, here are the steps we had to do to get this test restore environment up and running.

First support walked through the steps 1 - 14 of "Restore and Test SQL Report Server, Reporting Services, and Default Reports" BEFORE we did "Rename the Team Foundation Data-Tier Server and Activate the Team Foundation Application-Tier Server" AND "Move User and Service Accounts" section. Why? I'm not sure if I understood the reasoning.

Second, support did the following steps on the App Tier and Data Tier once I handed over support with Easy Assist.

1) App Tier: Before they ran RenameDT, they changed the ReportSever AppPool identity from NetworkService to the TFSReports account.
2) App Tier: They ran RSKeyMgmt.exe –d which deleted all encrypted data on the server
3) App Tier: They ran RSKeyMgmt.exe –r on the GUID from the initial install of TFS on this new hardware. Somehow this GUID gets re-added?
4) Data Tier: Opened up the tbl_database table in the TfsIntegration database and changed all the ‘servername’ values to the new Data Tier.
5) Data Tier: Opened the tbl_service_interface in the TfsIntegration database and changed ReportsService and BaseReportsURL to have the new App Tier name.
6) In Reporting Services Configuration, they made sure that the TFSReports account was used instead of a built in account.

After they did all this, the RenameDT worked. Like my first point, I'm not sure I understood why they did all this and if it was all really needed.

Third, after "Rename the Team Foundation Data-Tier Server and Activate the Team Foundation Application-Tier Server" we did the "Move User and Service Accounts" section. All this worked just fine.

Fourth, this wasn't really related to the restore per say, but we did have to give the AppTier\Users group Read, List, Read & Execute on the c:\Program Files directory. Without this, the only users that could log in where those who were members of the AppTier\Administrators group. I'm not sure if this is correct, or why the TFS install didn't set it up for us? When I compared this test restore hardware with our current PROD hardware, the current PROD hardware was configured with AppTier\Users have that access to c:\Program Files so we just mimicked the behavior and it all worked. UPDATE: We also had to give AppTier\Users Full Control access to %Program Files%\Microsoft Visual Studio 2008 Team System Web Access\Cache.

Fifth, we finished steps 15 - 29 of "Restore and Test SQL Report Server, Reporting Services, and Default Reports". This all worked fine.

Sixth, and lastly, we changed the Instance ID so that we didn't have the same Instance ID for both our current PROD hardware and our test restore hardware. See this full forum for how to do this.

After all this, we currently have a test copy of our current PROD system restored so we can play around with it.

What is needed to write complex Reports

There have been a number of people asking me what they need to install in order to get up and running with report writing using the "Business Intelligence Development Studio". Here is what I send them.

1) Install Visual Studio 2005. This step is optional.

2) Install "Microsoft SQL Server 2005 Express Edition Toolkit" which gives you the "Business Intelligence Development Studio (BIDS)"

3) Read Buck's blog and download the attached documentation to get your data sources setup and an initial report written.

4) Obtain a PHD in Computer Science if you have to write any MDX queries.

IE 6.0 crashes with Share Point 3.0

Some of our users have had IE 6.0 crash on them (intermittently) while opening up documents from Share Point 3.0. While the error messages don't exactly match, they are similar to what's described in Steve's post.

I followed up with the users and it seems that Steve's fix, fixes their issues with IE crashing.

Thanks Steve for posting your find!!!! I'm hoping it will get me a free beer at the bar.

Cannot create a connection to data source 'TfsOlapReportDS'. (rsErrorOpeningConnection)

If you ever see an error like below when trying to render a Report in TFS, make sure MS SQL Analysis Services is started under Control Panel > Services. Since we're running a duel server install, our MS SQL Analysis Service is running (or not running when we get this error) on the Data Tier.

An error has occurred during report processing. (rsProcessingAborted)
Cannot create a connection to data source 'TfsOlapReportDS'. (rsErrorOpeningConnection)
For more information about this error navigate to the report server on the local server machine, or enable remote errors

Frustrated with "How to: Move Your Team Foundation Server from One Hardware Configuration to Another"

Nothing frustrates me more than when documentation is wrong or misleading. Case in point: The document "How to: Move Your Team Foundation Server from One Hardware Configuration to Another" explaining how to move TFS from hardware to hardware is probably one of the worst written documents I've ever read. Here are just a few of my observations.

- We've bombed out at "To rename the Team Foundation data-tier server". The first issue was that a small, yet critical, detail is left out of the document. It's missing the statement explaining before running TfsAdminUtil RenameDT you must modify the Service's web.config, making sure the connection string on the new server is referencing the old server. The Community Content says this at the bottom and also the "Microsoft Visual Studio 2005/.NET Framework 2.0" says it. So why doesn't the master document for TFS 2008 say this? If you fail to do the rename, the command comes back and says "data tier name not changed."

- Even after getting past this, we are still stuck though. According the support, we actually should do the "Rename the Team Foundation Data-Tier Server and Activate the Team Foundation Application-Tier Server" and "Move User and Service Accounts" AFTER we do other things like "Restore and Test SQL Report Server, Reporting Services, and Default Reports" which is two sections BELOW "Move User and...". What? If this is true, which we're verifying with our field rep, why does the document have them out of order? How can someone expect to know this?

- Lastly, the support rep (who was actually very helpful by the way), said that you basically have to disconnect the old TFS server when you do the migration. Meaning, you basically can't do a test restore on some QA hardware before you have to come in on a weekend to do the same steps on a live PROD system. We're checking with our field rep to make sure this is accurate, but if it is, which I'm praying it's not, where in this document does it state that you must disconnect the old system before doing the restore based move?

Sorry for my rant. I just get so frustrated when documentation is wrong or misleading.

Running Tests and getting Code Coverage for our .NET projects.

As I wrote about a last week, the entire testing portion of Visual Studio is a mystery to me. I've never been a tester (for good reason) so I've really never spent the time to dig into Microsoft's offering. That was until I was forced to figure some stuff out, due to my new team wanting it.

From what I've found, TFS 2008 makes executing user's tests at build time very easy. All we had to do is add the following line to our Team Build project file and the magic happened. We had test results!!

<TestContainer include="$(OutDir)\Unit Tests.dll">

The code coverage was missing though so we had to track that down. Thanks to Benday, all we had to do is update our Team Project file again and magically, we had coverage results.

<RunConfigFile>$(SolutionRoot)\LocalTestRun.testrunconfig</RunConfigFile>

Of course this assumed our testrunconfig was setup for Code Coverage, which in our case it was.

So far, even a testing novice has found it pretty easy to get tests to run at build time. Feel free to share you experiences, both good and bad.

Publishing Test Results using the Testers Edition of Visual Studio

I fully admit, I don't know anything about the Testers Edition of Visual Studio. However, since I know a bit about TFS, I've been asked a number of questions about how the two talk to each other. Thus it's been a learning experience for me!

Here is the way I understand the Test Results publishing process to TFS for the Tester Edition of VS. Again, this is all really new to me so if I have something wrong, please correct me.

Per the document here, I see that a Tester will run a test on their local machine or using the "rig" to run on remote machines. After the tests are run, test results are stored in *.trx file on the tester's machine. Testers then can open that file and "Publish" them to TFS's operational store (which must be the TfsBuilds database maybe?). That data then gets moved to the TfsWarehouse per the warehouse schedule. At this point, you can Report on it in the warehouse.

Now there seems to be one small deviation in that Load Tests need to be loaded to a local SQL database which is defined outside of TFS. That is, the Load Tests database stores Load Test data before it's published to TFS. There must be someway then that the Tester Edition of VS can look in that local database where the Load Test results are stored, and publish the results to TFS. I think this is an important detail as there may be some ambiguity on the difference between the Load Test database and the standard databases that make up TFS (e.g. TfsBuilds, TfsWarehouse, etc).

If I have anything wrong here, I'd love for you to share your insight as we're trying to put the big picture all together.