Plunging into .NET Development

Weblog Pieter Gheysens
Microsoft .NET Development - C# - Enterprise Library - Visual Studio 2005 Team System - Compuware DevPartner - ...
 


Wednesday, June 25

Office 2007 Add-in : Save as pdf

Something I didn't know until today (thx Raf!), there's an Office 2007 Add-in available to save office documents (word, powerpoint, excel, ...) as pdf documents.

This download allows you to export and save to the PDF format in eight 2007 Microsoft Office programs. It also allows you to send files as e-mail attachments in the PDF format in a subset of these programs.

Friday, June 20

#8 - Source Server for TFS Builds

Category : Administering a Team Build

This is not yet a widely known practice in the field, but setting up a Source Server for TFS Builds in an enterprise development environment can be extremely valuable.

My friend and ex-colleague Jelle Druyts wrote a few months ago an excellent blog post about how to set up a Source Server for TFS Builds.

Anyone who will reference assemblies that are built with a source server enabled TFS Build will be able to debug those assemblies in the original source code ... great for framework code for instance!

When an assembly is "source server-enabled", the pdb file will contain the full path and the exact version of the file in source control that was used to build that assembly. If the debugger then enters a method, Visual Studio automatically downloads that correct file, places it in a local cache, and opens it for debugging. This is super sweet!

If you follow the guidelines of Jelle, you need to add the custom target RunSourceServerIndexing somewhere in your Team Build script, but he doesn't specify exactly where you need to include this.

Well, you have two options : you can do this in your TFSBuild.proj file or you can also put this custom target in an underlying .targets file to make it more reusable. The TFSBuild.proj file is the easiest option, but I would recommend an underlying .targets file. In fact it's always a good practice to make an underlying .targets file for all your common Team Builds. The idea is to make your .proj file as clean as possible and put all the logic and commands in an underlying .targets file.



In the image above you can see that I've created a specific target for all Compuware Team Builds on the Build Server. This .targets file must be imported in all TFSBuild.proj files.


To enable source server for my Team Builds, I'll just need to create a boolean variable in my TFSBuild.proj and pass it to the Compuware.targets file.



The Compuware.targets file will do all the required steps in the background. Note that the default is set to false for the variable SourceServerIndexing.



If you follow this pattern for other build tasks, you will end up with a clean TFSBuild.proj file and you will only need to pass booleans (and/or other variables) to the underlying .targets file that will contain all the reusable build tasks. Note that automatically all TFSBuild.proj files will import the default Microsoft.TeamFoundation.Build.targets file. Make sure that you never edit this master file, because it may jeopardize the working of your Team Builds when you need to migrate to another version of MSBuild.

Another small issue I came across when following the guidelines : the location where to drop the TFIndex.cmd file may be different than pointed out in the document (due to a different default location of the Debugging Tools). If that's the case you must also check the location of this file when you set the custom target RunSourceServerIndexing.



If you haven't taken the time to explore the possibilites of a Source Server for your TFS Builds, please do so now! You won't regret! And if you haven't been living in a cave for the last 6 months, you must be aware of the .NET Reference Source project that enables developers to debug .NET Framework code from within Visual Studio. Read more on the blog of Scott Guthrie (announcement made in January 2008). I guess that shares of Reflector must have dropped in value since this announcement ...

Labels:

Tuesday, June 17

#7 - Scrum for Team System (v2.1)

Category : Administering Process Templates

Scrum for Team System is a custom process template that you can install on your Team Foundation Server to provide your development teams with deep support for the use of Scrum. Scrum is becoming very popular in software development teams : it's an agile software development process to manage software projects. When applying Scrum (a rugby expression that refers to a way of restarting the game), software development teams use an empirical approach to adapt to changing requirements and priorities. The focus of Scrum is to deliver working software to the customer on a frequent basis. It's all about maintaining a Product Backlog and generating Sprint Backlog Items for dedicated Sprints. I've used the Scrum approach already in the past, but the (custom) process template we used at that time wasn't really good. The v2.1 process template of Scrum For Team System looks at least very promising at first sight.


I still have some remarks when installing v2.1 and using it on a Team Foundation Server 2008 :
  • Make sure you install the ScrumForTeamSystem virtual directory in the running Team Foundation Server website. That website runs with the TFS service account identity.
  • The home directory for the virtual directory is \inetpub\ScrumforTeamSystem by default, but for getting the included web services to run, you must give the TFS service account read & execute permissions on that folder
  • The Event Handler Service for updating the Remaining work (WorkItemChangedEvent) isn't configured correctly in the SQL Server database. You should check manually in the tbl_subscription table (TFSIntegration database) that the WorkItemChangedEvent subscription has the correct address to the webservice on the Team Foundation Server. I had to manually add the port number to the address to get it working.
  • If you still have issues getting it to work properly, be sure to enable the logging for the Scrum For Team System web services : edit the web.config by setting a value (logfilepath) for the LogFilePath setting. I can also highly recommend the forum to help you out.
Hopefully these issues will be resolved in the next release of the scrum process template installer.

Labels:

Monday, June 16

Need (visual) help with LINQ?

After LINQPad, you now also have Visual LINQ to assist you in writing LINQ to SQL queries.

LINQPad is more suited for programmers who already have some experience with LINQ and you don't need Visual Studio to start writing LINQ queries. Visual LINQ is well integrated with Visual Studio and visually assists you building LINQ to SQL queries. You can compare the add-in with the Microsoft Access Query Builder.

Labels:

Saturday, June 14

scenario for upgrading to TFS 2008

Recently I had an assignment at a customer to upgrade their existing team development environment (Team Foundation Server 2005 Workgroup Edition) to a full blown Team Foundation Server 2008. TFS 2005 (Application Tier + Data Tier + Team Foundation Build) was installed on a Windows Server 2003 machine. That (virtual) machine survived already many years (+4) of active development and it clearly became time to foresee a hardware move for the development environment. The plan was to put in place a more powerful machine with Windows Server 2008. So, there were 2 options :
  • Installation Windows Server 2008 on new hardware - Installation TFS 2008 on Windows Server 2008 - Move Team Projects from TFS 2005 (old server) to TFS 2008 (new server)
  • Upgrade TFS 2005 to TFS 2008 on old hardware - Installation Windows Server 2008 on new hardware - Installation TFS 2008 on Windows Server 2008 - move upgraded TFS to new hardware configuration
There were a few special requirements I had to keep in mind, for instance the request to move as little as possible garbage to the new hardware configuration. So I decided to go for option 1 and do a completely fresh install of Team Foundation Server 2008 on the new hardware. That way, we would have the possibility to move only the Team Projects we needed and the customer was also only interested in moving the source code - Work Item tracking was not really used during development ... and at that time I was still confident that we could easily move Team Projects with the TFS to TFS Migration Tool, a community tool that's based on the TFS Migration and Synchronization Toolkit.

Everything went as expected until we had to move the Team Projects from the old server to the new server. I will save you all the details of what went wrong, but in short the tool (for now) isn't really suitable for big Team Projects with a lot of history. In fact - something I didn't know until now - the tool will replay all actions that occurred in the past and this will take a lot of time when you're project has been around for a couple of years. Different other issues came up that concluded us to switch to the second option.

The new TFS 2008 machine was already set up, so the next steps were to upgrade the old server to TFS 2008 and to move the upgraded TFS to the new hardware configuration. There is a guide available that takes you through the required steps to backup all TFS databases and restore them on the new environment, but it still remains a tedious job where your utmost attention is required. One wrong step could endanger the move to the new server, so follow the guide carefully. When I was finished doing this, everything seemed to work at first sight in the new environment ...

Not completely actually:
  • Old Team Projects were available, but creating new Team Projects with the wizard failed time after time due to an error during the Work Item Type Import (Error TF30170). After investigating the logfile I absolutely had no clue what was causing this and the inner exception I found resulted also in no hits in my favorite search engine. So, here's my entry in the TFS Work Item Tracking forum.
  • The next day, when the old server was put offline (Team Foundation website was already stopped before), the new Team Foundation Server on the new server stopped working. Connecting to the database wasn't possible anymore (error TF30041 : Team Foundation Server could not connect to the database). What?! The only possible explanation could be that the active Data-Tier was still the old server because putting the old server back online solved the connection problems. The guide I used for the move mentions the rename command for the Data-Tier Server and I was sure that it didn't raise any exceptions/warnings while executing this. Also after re-executing this command (TfsAdminUtil RenameDT newTeamFoundationDataTierServerName) it didn't seem to overcome the connection problems we were faced. So, we had to fix this the hard way without an automated command :
    • First thing to verify was the ConnectionString in the web.config of the Team Foundation Services (\Program Files\Microsoft Visual Studio 2008 Team Foundation Server\Web Services\Services\). The Data Source in the ConnectionString should point to the new new server. In our case this setting was correct, so no manual changes here.
    • Next thing to verify was the server name that's entered in the TFS SQL Server Database TfsIntegration. In the table tbl_database all rows should have the new server value for the servername column. And that's what was wrong in our case : the active server name was still the old server name. Here we manually changed the value to the new server name, did a reboot of the server and everything was ok now - no more references to the old server.
Note that I do not recommend to manually edit data in the TFS SQL Server Databases. If possible, use the appropriate tools to get results, but here we bumped into the fact that TFSAdminUtil let us down.

Labels:

Tuesday, June 3

Live Mesh

Heard already about the new buzz : Live Mesh?

Live Mesh puts you at the center of your digital world, seamlessly connecting you to the people, devices, programs, and information you care about— available wherever you happen to be. Here, there, everywhere ...

Today I tried to sign up and see what I actually can do with live mesh ... but due to the success of the tech preview, I'm on a waiting list. To be continued!

Thanks for your interest! Our tech preview program is currently full. If you've already signed up, we'll send you an e-mail as soon as more space is available.

Some oneliners taken from the learn more section :
  • All your devices working together
  • Access from anywhere
  • Simple to share
  • Stay informed
  • Protection you know

Labels:

MSDN Evening Sessions