Skip to content

Putting it out there…


Tag: Visual Studio 2008


I found a nice tutorial on Josip Medved’s blog. I’ve copied the article below for back-up purposes.

How to connect VS2008 with TFS 2010

Team Foundation Server 2010 works great when combined with Visual Studio 2010. However, if you wish to combine it with Visual Studio 2008, some additional setup is required.

First thing that you need to install is Team Explorer 2008. If you already used source control, you may have it. Easiest way to check is to go into Tools > Options and select Source Control. If there is “Visual Studio Team Foundation Server” in plug-in list, you can skip this download.

Another thing I installed was Visual Studio Team System 2008 Service Pack 1 Forward Compatibility Update for Team Foundation Server 2010. I do not think that this long-named update is really “must” but I decided to install it anyhow – just in case.

Once you install everything, you can try adding Team Foundation Server 2010 as destination, but you will be greeted with error “TF31002: Unable to connect to this Team Foundation Server …”. Reason behind this is that old Team Explorer 2008 does not know anything about collections.

Solution would be to add it as full path (e.g “http://server:8080/tfs/collection”). I could not do it because every time I entered full path, I also got error “TF30335: The server name cannot contain characters ‘/’ or ‘:’ …”. Since official way would not work it was time to come up with alternative.

In order to add TFS 2010 server, you will need to exit Visual Studio 2008 and go into Registry editor. Find key “HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\TeamFoundation\Servers” and at this location just add string value. Name of this value will be what Team Explorer 2008 will use for display. It’s value is full address of your server. It should be something like “http://server:8080/tfs/collection”.

Now you can go into Visual Studio 2008 and Team Explorer will have new entry. As you work with it, you will notice that not everything is “bump-free” (e.g. tasks). However, source control it self will work perfectly and that was enough for me.

The problem

Today I wrote some tests for a project I’m working on, which uses the FileHelpers library.

When I tried to run the tests, I received the following error:

Failed to queue test run ‘mbev@WSXP-BE-6833 2010-08-31 11:51:43′: Test Run deployment issue: The location of the file or directory ‘c:\pathToProject\business.tests\bin\debug\FileHelpers.dll’ is not trusted.

First thing that went through my mind was: “Man, I’m trying to introduce testing in this environment and then I get this. Why is everything working against me?!!”. Nevertheless, I put my personal issues aside and worked on resolving the problem.

In the past I’ve encountered a similar issue, but then I was working with network shares. Visual Studio has trust issues with other machines then your own. It that were the case, you can resolve it using CASPOL (Code Access Security Policy Tool). But I’m working on my own machine, on a local drive, my system drive!

The Solution

Suddenly, I remembered that Windows also has trust issues with external dll’s and exe’s. The solution is extremely simple! You can resolve it by clicking two buttons: Unblock and OK…

Restart Visual studio and you’re good to go!

Filehelpers Properties - Blocked

The Problem

A few days ago, I was toying with WiX (Windows Installer XML). When working with WiX, you need Guids for your product ID, upgrade ID, installer ID, …

To compile my installer, I needed valid Guids. So instead of always going to the web and use a guid generator, I decided to create a Macro in Visual Studio (2008) and link it with a shortcut to my keyboard.

continue reading…