Headaches and TFS Migration: Moving databases to another SQL server

 

You may get this message if you attempt to migrate your databases to another server and then install the TFS server as an Application Tier only, pointing to the aforementioned database:

TF254006: No usable accounts are present in your configuration database. Use TfsConfig accounts /add to add an account and return to this wizard.

The reason is that the owner of the database on the new SQL server is set to nothing.

1. Open ‘security\users’ on the ‘tfs_configuration’ database (or the name of your configuration database)

2. Add the domain user you will be using for TFS (which should already be a user on the SQL server) to the ‘tfs_configuration’ database.

3. Make sure when you create the user above, you tick ‘TFSADMINROLE’ and ‘RFSEXECROLE’ as seen below.

4. Try and connect to the database again in the application tier, and all will work!

Headaches and TFS 2010 Migration: Database backups

If, like me, you need to move your TFS 2010 databases from one machine to another in order to create a separate application tier, one of the tasks is to shift the database from one machine to another.

Alas, when backing up the database on your existing SQL server, you may receive the following:

Microsoft SQL Server Management Studio

Backup failed for Server 'TFS2010'.  (Microsoft.SqlServer.SmoExtended)
ADDITIONAL INFORMATION:

System.Data.SqlClient.SqlError: A nonrecoverable I/O error occurred on file "e:\temp.bak:" 112(failed to retrieve text for this error. Reason: 15105). (Microsoft.SqlServer.Smo)

The reason for this obscure error is that your TFS database is very, very large. Your disk on the other hand is very, very small. You therefore have 2x options.

1. Delete files from the disk

2. Try and export with the ‘WITH COMPRESSION’ command.

In order to attempt the latter, you need to script to a new query window as you can’t do it from the UI.

Within the query window, add ‘WITH COMPRESSION’ so that it looks something like this:

BACKUP DATABASE [Tfs_DefaultCollection] TO  DISK = N'e:\temp.bak' WITH COMPRESSION, NOFORMAT, NOINIT,  NAME = N'Tfs_DefaultCollection-Full Database Backup', SKIP, NOREWIND, NOUNLOAD,  STATS = 10
GO

Perfect! Your database should now end up on the disk, even if you don’t have a whole lot of space left. Note that the export and compression will likely take a long time (just over an hour for our TFS database)

Headaches and Compiling C++ .NET 3.5 projects under VS2010

 

Background:

One of our partners released some open source components in the form of C++ assemblies, which we consume in our product. I needed to recompile one of them today. By opening the VC++ project in Visual Studio 2010, they were automatically upgraded to .NET 4.0. This is no good, as our product is currently running 3.5 and subsequently wouldn’t load the compiled assemblies.

So, I needed to make the assemblies compiled under 3.5 within VS2010. Turns out this isn’t as obvious as I was expecting.

Solution:

1. Open the ‘*.vcxproj’ file within a text editor.

2. Find the section titled ‘<PropertyGroup Label="Globals">’ and add in the following line within it:

<TargetFrameworkVersion>v3.5</TargetFrameworkVersion>

3. Open the solution within VS2010 and right click –> ‘Properties’ on the project.

4. Click on the ‘Common Properties’ section and verify that it says ‘Version=v3.5’

5. Click on the ‘Configuration Properties’ section and change the ‘Platform Toolset’ to ‘v90’ (.NET 2.0/3.0/3.5)

If you get any errors when you build, you may need to verify that the C++ components are installed as part of your VS2008 (yes – 2008) installation. You can verify this by opening up ‘Programs and Features’ in Control Panel and click ‘Repair’ while focused on the VS2008 Team entry in the list.

Headaches and Hacking C++ Strong Named DLLs

Background:

We had a problem with an hardware manufactures SDK, whereby one of their assemblies (for which we had the source code for) was throwing an unmanaged exception, killing our software.

I got in contact with their support, who provided us with some modified source code. After getting it compiling under C++ VS2010 / .NET 3.5 (another Headache in itself) I ran into problems with some of their other DLLs which are strongly signed refusing to load the assembly that we’ve recompiled. Guess what… we don’t have the strong key in order to resign the assemblies, and don’t have source code to all the other assemblies to recompile them without strong names!

That’s where Reflexil comes in!

Awesome little tool I found today, which allows you to hack around with compiled .NET assemblies.

1. Download and extract Reflexil anywhere you want.

2. Open Reflector, goto ‘View’ –> ‘Add-Ins’ –> ‘Add’ and select ‘Reflexil.Reflector.dll’

You now have it installed! Click on the ‘Reflexil’ item in the ‘Tools’ menu to load the right hand bar.

Using Reflexil you are able to remove the strong names from the DLLs that don’t belong to you, so that they will then load the ‘rogue’ DLL that I’ve just recompiled without the original strong name key file.

Click on the assemblies and remove the ‘HasPublicKey’ checkbox on each one. Clear the ‘PublicKey’ and ‘PublicKeyToken’

Note that if you have assemblies that reference each other, you will also have to go through each of the references for each assembly, and remove the public key information from each reference as well.