September 2006 Archives

So, this isn't exactly original material - but I was having a chat with somebody today who I consider very knowledgeable about Visual Studio Team System and they were not aware of these so hopefully re-posting some will help more people discover them.  Strictly speaking, as all of these have been mentioned somewhere before the word "Secret" isn't correct - however it gave an otherwise very dull post a certain bit of excitement which kept you reading this far so forgive me.  The usual Caveats about messing with the registry apply, also the default settings are generally more logical to new users so use with caution.  Most of these tips apply to HKEY_LOCAL_MACHINE as well as HKEY_CURRENT_USER - I normally set them as a user preference so as not to confuse anyone else that should happen to use my machine.

Hack #1 - Stopping Team Explorer from connecting on Visual Studio 2005 Start-up

Add a DWORD value called "AutoLoadServer" under HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0\TeamFoundation.  Zero means do not reconnect automatically.

I first read about this setting over at Tim Noonan's blog.  This can be very handy if, like me, you frequently change TFS servers.  I jump between the work TFS instance, CodePlex and a test or VPC versions of TFS.  I know which server I want to connect to when starting VS 2005, and frequently it is not the one I connected to last time.  Adding the following setting means that I have to manually pick the server I want to connect to from the "Add Existing Project..." button.

Hack #2 - Don't get Missing Files

Add a DWORD value called DisableGetMissingFiles under HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0\TeamFoundation\SourceControl.  Any value other than zero will disable getting files from the server automatically.

Another Tim Noonan special.  This setting determines if files missing from the solution or project are automatically downloaded.  I normally switch this off and so get the files only when I say "Get Latest" on a particular solution or project, this is especially useful when you are not always connected.

Hack #3 - Bypass proxy server

Add a String value called BypassProxyOnLocal under HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0\TeamFoundation\RequestSettings.  A value of "true" will bypass.

This one from the legendry Buck Hodges.  In some network configurations, the Microsoft Team Foundation Server client will connect to your Team Foundation Server via a web proxy server.  This should be avoided as it slows everything down and the NTLM authentication used by TFS doesn't play well with some proxy configurations.  I've seen this pop up as a problem with environments that use a proxy.pac file to control proxy access rather than hard-coding the entries in the Internet Options, LAN Settings (or for folks that don't have Bypass local set up).  You should probably only use this setting if you know you are having this problem (often diagnosed by an intermittent failure of Team Explorer to connect but easily checked using a network sniffing tool such as Ethereal).

Hack #4 - TFS Version Control Proxy Settings

See HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0\TeamFoundation\SourceControl\Proxy.  A String value called Url containing the proxy address and a String value called Enabled set to true will enable the source control proxy.

The easier way to enter values for what machine to use as a TFS Version Control Proxy is to go to into Visual Studio with Team Explorer installed and select Options, Source Control, Tools, Options, Source Control, Visual Studio Team Foundation Server, Proxy Settings.  However, if you are running a tf.exe script or TFS .NET API code as part of a service and you want the code to go via a proxy then the HKEY_LOCAL_MACHINE version of this setting is very useful for setting a default.

Hack #5 - Configuring the TreeDiff Power Toy

See Brian Harry's excellent post about some registry tweaks for Configuring the TreeDiff Power Toy to your whim.

Just wanted to let folks know that Preview 2 is now available for download to our preview program customers.  If you want to take a look at Preview 2, then you can sign up here.  This preview release builds on the code we released last month in Preview 1, including some new features, lots of performance improvements and also suggestions from our existing Preview Program community.

What is new in Preview 2?

A lot of the changes this time are under the hood - many of which you won't notice if you've been happily using Teamprise so far, but they are based on our performance and scalability testing.  We actually have made significant changes to our web service proxy layer to make it much faster and orders of magnitude more memory efficient - especially for servers with a large number of Team Projects.  The command line client start up times are also significantly improved.  There were however some new features that everyone will notice:-

Branching support. 

You can add branches and view the branches of a file from within the Source Control Explorer.  Branch merge functionality is still not completed, if you really wanted you can go through the Merge wizard up until the point where you are about to perform the merge, and then you will get the "Feature not yet implemented" message.  Merge will be in the next preview once we have worked through all the possible merge conflict use-cases.

 Label Support. 

You can now apply, modify and search for labels.  It may seem that this has taken us a while to get into Teamprise.  The reason for the delay is that there were some slight differences in the way our .NET SOAP stack interpreted the WSDL for the one of the label methods in the TFS web service.  In all the tens of TFS web service methods we talk to from Java, this was the first one that we hit an interoperability issue with.  Fortunately, because of the work we did in our SOAP proxy layer to improve performance we have also been able to fix this issue meaning labels are now available.

Better Off-line Support

This one jumped up the priority stack due to feedback we got on the forums and via email.  Due to the nature of the Team Foundation Server protocol in V1 we do not have full off-line support.  However, in Version 1 of Teamprise we errored a lot if you tried to work in Eclipse while disconnected from the network.  In V2 Preview 2, if you are unable to connect to the server the plug-in will prompt you if you would like to work offline and will not attempt to talk to the server again until you restart Eclipse.  You can get on with some work as long as you understand that you are responsible for manually syncing your changes up when you next connect to TFS.  To edit a file while offline you must manually mark it as read/write.  You should avoid renaming or deleting files while offline.  When you next connect, all the read/write files will have a little question mark on them inside Eclipse.  First thing you should do is to Synchronize your project (Team, Synchronize).  This will then show you files that you need to add and files that have changed on the server while you were offline.  You can safely pend adds for all your files here.  Then you need to go back into package explorer and mark the files that you edited as read-only and check them out again.  TFS does not overwrite these files with the latest version when you do a check out.  Finally you need to check-in all your changes.  While this is by no means perfect, it allows you to do some work should you not be able to connect.  In future versions we hope to improve the offline story significantly.  Thanks again to all our preview program volunteers for letting us know about this, please let us know if this helps.

Work Item Improvements

A lot of work has gone on under the hood with the work item area making it more reliable and handling many more of the edge cases around peoples customized process templates (again, largely thanks to feedback from our existing preview program community).  There have been some other new additions, my own personal favorite is that you can now do a work item search from within the Pending Changes view, making it even easier to track down that work item that you want to associate your check-in with.

I would like to thank everyone so far who has sent in comments from being part of our preview program.  It gives all of the development team invaluable feedback to ensure that we have a great V2 product when it ships later in the year and also that people looking to purchase V2 get the product that they want.  Keep the feedback coming, it is great to hear from you.

Visual Studio Team Foundation Server gives a fantastic ability to track and report on various facts about your software development process.  It frees managers (and team members) from the chore of recording and collating data about the development process.  Managers can now get on with managing the project - removing obstacles before they seriously impact the team, reporting on the progress of the project to its owners and organizing deliverables to maximize the productivity of the teams.  With all new powers, there comes some danger and the need for responsibility (just ask King Midas or the scriptwriters of countless Hollywood films). 

The Uncertainty Principle

The uncertainty principle was first enunciated by Werner Heisenberg in 1927.  Broadly stated is describes that we can know the path an electron takes as it moves through space or we can know its position as a given point in time - but we can not know both.  Any attempt to measure one will unavoidably disturb the other.  What Heisenberg proved is sometimes improving the instruments won't help - a measurement affects the thing being measured and that it is an immutable property of the universe.

The reporting aspects of Team Foundation Server are a new, more accurate, instrument to take measurements inside your software development process but you need to be wary about the things you do measure.  The metrics need to mean something useful rather than just be interesting.  The affect of taking the metric should be carefully considered before taking it.  This is not a new problem that Team Foundation Server has introduced, just that because it makes it so easy to get data out of the system the temptations are greater.

Lets take an example of measurements affecting the process in the world of business rather than in the world of quantum mechanics.  In the UK, we recently had our telephone directory enquiries system de-regulated.  This meant that instead of just one number to dial when you wanted to get the telephone number of the local pizza shop, you now have a multitude of providers offering you that service.  After a few months, a study was carried out by a consumer organization to rate the different telephone directory information companies.  When a person calls directory enquiries, their goal is that they get the correct number for the person or service that they require - therefore when the consumer organization did the study they looked at accuracy and cost of the call.  Costs were more or less equivalent across the new companies - a one off charge of 50p per number.  The thing that surprised everyone is how in-accurate many of these new companies were.  All the companies talked to the same central number database so there must have been something else going on.  It turned out that many of these call-centers bonused their staff on the quantity of calls they got through a day - a reasonable measure for the company as there is a direct relationship between numbers of calls and revenue. The problem with this measurement is that it is in the interests of the staff not to bother being accurate, but to give the person a number (any number) to get them off the phone and move onto the next.  It only takes a couple of times for a customer to call one particular directory service and be given the wrong number for them to stop using that company and go with a more reliable one...

Similar things happen in the software development process.  For example, I think it is a bad thing to look back at an iteration and ask the question "who did what".  The more useful measure is which requirements did we solve and how many hours did we collectively spend doing this.  There are a few reasons for this. 

In any software team there are different characters that are needed.  Take the software developers for example (because this is the world I tend to live in).  You have the "hardened pros" who can just sit down, concentrate on their task and churn out the code, you have the "junior" people learning more and you have "floaters" - people that tend to move around a bit helping others out while getting on with their own deliverables when nobody is blocked.  In any large development, you need this mix of people.  Too many floaters and you spend your time discussing clever frameworks to reduce the amount of code needed to be churned out, Not enough floaters and you find that tasks can get blocked for weeks on end.  The same is true of all the characters in the team.  You need a mix of them, and you need them to work as a team for the benefit of the software development overall.

Measuring an individuals productivity is incredibly hard, because you can measure certain facts (such as how many lines of code did they write a day, how many bugs and tasks assigned to an individual have been resolved) but do these facts tell you anything about how good a person is at their job or how much they individually contributed to the success of a project?  As Heisenberg showed us, the downside of measuring is that this affects the process.  If individuals within a team are rated based on how many tasks they have completed then this inevitably leads to people being more selfish.  They are more likely to ignore somebody who is stuck on something, and concentrate on making their own score as high as possible.

In a large development process, it is frequently healthy to have a certain amount of competition between teams.  This bonds a team together and makes them collectively strive to out-do the other teams increasing productivity.  The downside of competition between teams is that it increases the feelings of "them-and-us" between groups, which can often get in the way of successful delivery.

I'm afraid that I have no easy answers, and no silver bullets.  There is nothing I can say "you must do this" and "you mustn't do that".  This is because software development is a hard and complicated problem that depends on the individual circumstances you face and the goals you are trying to achieve.

Team Foundation Server is a fantastic new instrument that allows a manager to take accurate measurements of their software development process, but you should keep Werner Heisenberg in mind, think about what the affect of taking the measurement will be and resist the temptation to abuse your new found powers.

We've just been having a discussion internally about ways of numbering our builds.  It seems a sensible idea to qualify a build with the changeset number in our TFS repository, that way we are able to easily identify the exact status of all the files included in that build without the need to add a label into TFS.  My thought process when figuring out how to get the data was a typical one so I thought I'd post it here...

Idea 1)  My first thought was to go directly to the web services.  I know there is an Administration web service for VersionControl that gives you lots of nice jucy stats about your TFS instance including the maximum changeset ID (the QueryRepositoryInformation operation on http://tfs_at:8080/VersionControl/v1.0/Administration.asmx).  However, as I've ranted about before, going against the web services should always be avoided and only used as a last resort when all other alternatives have been ruled out - so I thought I'd try to resist the temptation and do it another way.

Idea 2)  Well, in that case I thought I'd use the API.  I could have done this using the .NET API, but as I work for Teamprise, I have access to our Java API which has the advantage of running from our Unix build server.

Idea 3)  Then I realised, I didn't need to do any of this rubbish and that the functionality was already available with careful use of the Command Line Client (tf) - again Teamprise has a version of tf that runs from unix so I can happily use my commands on our unix box as well.  (For those new to tf then see TFS Top Tip #4).  In the end, the command I needed was:-

tf history /s:http://tfs_at:8080 /stopafter:1 /noprompt /recursive /version:T $/MyProject/trunk

Simple really.  But I thought this illustrated a key point about using TFS.  Because the capability for extension is so huge, the temptation is to use it when often you can simply do it in the UI or from the command line.  If you cannot and there isn't a tool already available to do it, then you should look to the tried, tested and performance tweaked API.  Finally, if the method really isn't exposed in the API then you could go direct to the webservices, but you are now in the territory of being un-supported and things may well break as new versions of TFS are released.

People might suggest you go direct to the database, but there are many reasons why you shouldn't.  Mainly that unless you work for the TFS teams at Microsoft you'll probably do it wrong.  Also a lot of data is cached in memory in the Application Tier - messing with the database under the hood is a sure-fire way of corrupting your TFS instance.  The final reason is that if you corrupt TFS by messing with the tables after all these warnings, don't be expecting anyone to help you.

I just discovered Microsoft Max.  While the application still seems to be in the early stages, it has to be the prettiest application I have ever used - just take a look at the semi-transparent splash screen with it's lovely wobbly progress bar. 

This is currently a photo-organizing/sharing app based on top of the WPF and WCF stuff in the .NET 3.0 release (think Picasa but from Microsoft).  I'm pretty happy to see that my Dell M70 with Nvida Quadro FX Go 1400 graphics card qualifies as a "Tier 2" device for WPF world - hopefully signifying a Vista upgrade will actually give me the fancy look and feel.

As far as the application goes - currently it allows you to automatically share photos with your friends so that they automatically receive new photos inside Microsoft Max.  It also has a decent RSS aggregator.  Apple has something similar in the iLife suite of products for Mac OS X, I think it is iPhoto, don't remember.  Anyway the use case I have in mind is an easy way for my father to get the latest photos of my family growing up automatically on his desktop so that he can print them / burn them to DVD.

However, while Microsoft Max looks incredibly nice, there are some problems with the current architecture as I see it.  The main one is that without the equivalent of a .Mac account, files are transferred directly between my machine and my fathers - meaning both machines have to be on for this to work.  It also has to make it through the multiplicity of NAT's, firewalls etc separating our machines.  I hoping that there is a backing Windows Live online service in the works to help with this, we'll see.  The fact that you have to have a MS Passport to use the software certainly suggests that this may be the case.  The lack of information on the Max web site leads you to think that this is the basis of some sort of social network type application - more indications that in the Web 2.0 world Microsoft are stepping up the pace to justify a specific OS to be an ideal complement to peoples new online lifestyles.

Anyway, this bodes well for applications coming the pipe from Microsoft to make Vista a more consumer friendly OS.  Also it shows what can be done with WPF. 

While WPF has me very excited, I'm also a little scared.  You are going to have to have a modicum of graphical talent to use WPF sensibly or you could very rapidly have a very ugly application.  It's looking like application vendors are going to have to hire some of the creative talents from the games studios to make apps that are visually pleasing. 

One thing is certain, the Windows world is going to have a revolution in UI design over the next 5 years - probably the biggest change in the history of Windows - and anyone not keeping up is soon going to have a very dated looking application.

Brian Harry has been on a blogging spree this week!.  Last night he announced some new Team Foundation Server Power Toys.  This also shows a new and very welcome trend from Microsoft's DevDiv - the Power Toys are available as a separate download, but more interestingly many of them also integrate seamlessly into the IDE.  This is a great way of providing new features to customers in a much more Agile fashion.  It is fantastic to see a large company like Microsoft being able to move in a more nimble way and not have to wait for that big release train to come along.

There are many interesting things in the Power Toys and the supplied word documentation is also pretty good.  There are a new set of commands for manipulating work items from the command line (a bit like the "wit" command in Teamprise) - however Microsoft have implemented a feature which we had discussed internally but not got around to yet, which is output as XML.  Anyone that has tried to write some sort of shim over the existing tf.exe commands will know how hard that is - output as XML gives a very easy way of making the command line computer readable.

If all that was not enough - Brian has also announced that support is now available for the MSSCCI provider.  This is also very welcome news for adoption of Team Foundation Server.  Visual Studio Team System will handle IDE integration for VS 2005 and up, the MSSCCI provider will all the older Visual Studio products you are likely to come across in an enterprise and of course Teamprise can enable your Java or Embedded developers and the folks running Mac, Linux or other flavors of Unix.  This means that an organization can migrate all its development efforts into Team Foundation Server.

Brian Harry has recently posted an excellent word document talking about some guidelines to follow when developing custom TFS extensions.  The document is definitely worth a read as it gives you a better understanding of the issues behind the guidance.  It is quite Version Control API centric and it would be nice to see similar detailed advice regarding the WIT stuff, but some of it (especially the first tip) holds true for all aspects of TFS integration.

I had started ranting about how much I agreed with the document, but I've just deleted the rant as it was getting in-coherent.  Just let's say that you should really pay attention to this 3 paged document if you are writing a TFS integration - take it from somebody who found out many of the lessons the hard way :-)

We have some friends staying with us from out of town at the moment.  They are actually friends of my parents - the type of people that were always around when I was growing up and I called my Aunt and Uncle even though they are not blood-relatives.  Anyway, they have recently retired and have decided to buy a computer and get on the Internet.

Considering they have never really used a computer in their lives, it is really interesting to see how well they have got on.  Impressively, they have managed to download pictures from their digital camera onto their hard-drive and print them out.  Also, they have recently managed to transfer some songs from CD's onto an MP3 player which they brought with them on Holiday.

The discussion I found particularly interesting was a discussion they had between themselves about the annoying pop-up dialogs that come up every now and then.  Having heard many scare stories about viruses etc - they are concerned about *any* dialog box that pops up when they are working as they are scared that it is some nasty script kiddie trying to trick them into stealing their credit card numbers.  Most modal dialog boxes they ignore and try to get rid of as quickly as possible - avoiding the "OK" button unless they really know they want to do it.  Anyway, the conclusion that they had come to between themselves was:-

If it says "Upgrade" then you have to pay.  If it says "Update" then it is usually free and safe to accept.

An interesting (and often correct) assumption I thought.  Anyway, the whole day left me with a realization that I need to be more precise in the language used to convey messages to users - I'm also going to be sure to try to pick words that are easily translatable for folks who happen to be using a system in a language that is not their first.  It's fascinating to see the coping strategies that people adopt when using unfamiliar technology - but also frightening how far we have yet to go to make consumer electronics more friendly to the "normal" people that we would like to buy them.

I've been involved with Indigo for exactly 2 years this week, through the various changes in product name.  Anyway RC1 of .NET 3.0 was released yesterday (just under a year since .NET 2.0).  I'm currently downloading it and will install over my beta version of WinFX.  I'm quite interested to find out if the .NET Framework assemblies get revved at all or if the framework has the same v2.0.50727 libraries that were released with .NET 2.0 last year + the WinFX stuff.  I'll soon find out...

Update: Looks like it is .NET 2.0 + WCF, WWF and WPF (which I'm very glad about to be honest).  Right then, off to have a play with my TFS Proxy Sync service (which uses WCF to listen to check-in notifications from the Team Foundation Server...)

Next week you can have the opportunity to join the VSTS product group to discuss the features available in the different editions and Team Foundation Server.  If you have some feedback that you have been dying to give about the product then this is a great opportunity to influence the team directly.

Join the chat on Wednesday September 6th, 2006 10:00am - 11:00am Pacific time (6pm BST)

To see your local time of when this chat is, click here.