jesfer

Recently one of my clients (who uses TFS 2008) encountered the TF14083 warning when merging two branches. This is the warning message:

The item '{0}' has a pending merge from the current merge operation, please resolve and check in the current merge and merge again to pick up this change.

In most cases this is nothing to worry about, all you need to do is just what it says in the message. Resolve, check in and merge again.
But a cautious user might start to think along the lines of "so,what happens if the second merge fails? I've already checked in the first part of the merge!". The simple answer would be that you do a rollback to the previous changeset using TFS 2008 Power Tools.
However, in TFS 2008 the rollback will only rollback the actual changes but the merge history will not be affected and this will cause trouble when you try to redo the merge operation as TFS believes the two branches have already been merged. You can probably solve this dilemma by doing the merge using TFS command line tool and use the /force option but by now most people are thinking something along the lines of "this is stupid, TFS should be able to handle all this".

And if you move to TFS 2010 it can! Not only has one of the main reasons for the error above been fixed, but rollback is now part of the standard TFS command line tools and has an option for keeping merge history or not. There, another good reason why you should move to TFS 2010!  

I finally found some time to get my blog up and running again. Even found a nice theme to use. Needs some tweeking but it is good enough for the moment.

I have no idea why my blog died on me (bored from inactivity maybe) but instead of debugging it I choose to just move on to BlogEnginge.Net 1.5. Exporting settings and posts was more or less a matter of copy/paste :)

This is actually really easy as long as every developer on your project makes the move simultaneously. If not, well, there are a couple of things to keep in mind.

• VS2008 will convert your solution and project files even when you stay in .Net 2.0. Converted solution files can not be opened by VS2005. Project files can still be opened (you'll get a warning but that is all). This means you'll have to work with two versions of your .sln files, one for VS2008 and one for VS2005.
• If you've used Microsoft's Test Project template for writing unit test etc, the reference to ”Microsoft.VisualStudio.QualityTools.UnitTestFramework” will have changed in the conversion, breaking the project for VS2005. This reference will have to be manually changed back and forth depending on what VS version developers use.

That's it so far, but I'm sure there are some other pitfalls out there waiting for me :P

I was recently asked to bugfix an application. The bug was eaasy enough to fix, just add two lines of code, no big deal. In order to build the application I had to install Enterprise Library 3.1 and re-reference a few .dll files in it. Also no big deal, done it before with previous versions of Enterprise Library... but it turns out i stumbled right into a configuration pitfall!

Short version for those who dont want to read Tom Hollander's blog about Avoiding configuration pitfalls with incompatible copies of Enterprise Library:
If you install Enterprise Library 3.x a go with all default options/choices, you end up with two sets of .dll files. If you have to re-reference these files in a project and use the wrong .dll your code will compile but throws an exception in runtime... referencing the other set of dll files will solve the problem (but might cause new problems as well).

Problem:
After locking Vista some letters on my keyboard act as hotkeys. U (which is in my password) brings up the "Ease of Access" window. Needless to say, this makes the login process impossible to complete.

Cause:
This only happens if I run Virtual PC (2007) when locking Vista. So I guess VPC is to blame, but I'm sure there are other programs out there that might cause this behaviour too...

Solution:
Quite simple really. Click the "Switch user" button and select your own account. Hotkeys are gone!

Objective:
Get a VS2003 ASP.NET web application project from SourceSafe, migrate to VS2005 and add to TFS source control. All done on a PC running Windows Vista. As VS2003 will not run on Vista opening the solution in VS2003 and disconnect it from source control is not possible... might be possible to do from SourceSafe, but I decided to give it a go and just open it in VS2005 straight away.

Problem:
VS2005 conversion wizard fails to convert the web application. Depending on if I let the .sln file point to localhost or changed the projekt path to "C:\myAppPath\myWeb.vbproj" I get two different errors:

Error 1 (keeping localhost/myWeb/myWeb.vbproj as project path):
Conversion Issues - myWeb.vbproj
Thats it... No clue as to what is wrong.

Error 2 (changing to C:\myPath\myWeb.vbproj as project path):
Conversion Issues - myWeb.vbproj:
Unable to open the Web 'C:\myPath\myWeb.vbproj'. The Web 'C:\myPath\myWeb.vbproj' does not exist.
Looks a bit more helpful, but since the file DOES exist... No, no more helpful than what I got in Error 1.

Solution:
As it turned out there wasn't really anything wrong with the myWeb.vbproj file. Except that it was write protected... Checking the "make writable" checkbox when getting the code from SourceSafe (or just removing the write protection from the file) made all the difference. VS2005 disconnects the code from SourceSafe source control and converts everything 

Now I just need to solve all the compilation errors and the code will be ready to check into our TFS... Looking back, I might have been able to avoid the entire problem by following Microsoft's instructions for migration. But why learn to swim when it is soooo simple to just jump into the deep end of the pool? Anyway, hope this is helpful to someone else...