But it works on my PC!

When your PC reaches the point that MSI cannot connect to the Install Service you know it is time to repave the PC. This is the time to you have to try remember what you installed on the PC, your license codes and how you actually got things to work.

So going through this process this week all went OK until I tried to remember how I handled bitlockered VHDs.

My PC does not have a TPM chip, but I wanted to bitlocker as much of my data as possible. The process to do this was as follows:

• I created an empty folder c:\projects
• I opened Computer Manager, then Disk Management as an administrator.
• Via the Actions menu I created a new VHD c:\VHDs\projects.vhd
• This will be mounted by default onto a drive letter, I changed this to mount it on a path (the one I created in step 1)

• Then via the Disk Management tool I created a partition and then formatted the new disk.
• I could then go onto the new disk by changing to the C:\Projects directory
• I now needed to bitlocker the new VHD drive. This is done via the Control Panel | loaded the Bitlocker Drive Encryption

• As I had no TPM chip I have to encrypt the drive with a password.
• So when this finishes I have my C:\Projects directory this is a mount point for the bitlockered VHD

But I did not want to go into disk management each time I booted to attach the drive; but I did not want it automatically mounted as that defeats the purpose that I wanted a drive that could only be accessed via a password on a reboot..

To get around this I added a shortcut to the project.vhd file to my desktop. To be able to click this to attach the VHD I installed the vhdattach untility(http://www.jmedved.com/vhdattach/). This allowed me to right click the VHD shortcut and attached it, at which would I am prompted to enter the bitlock password for the VHD,.

So I now have a means attach my drive (fairly) easily even though I have no TPM chips. Just wish I had written down how I did it before so I did not have to work it out again.

It is not a perfect solution but at least my important data is bitlockered.

Whist recently installing a TFS 2010 system onto a single box server, that was also a domain controller, I had a problem that though everything seemed in order I could not view my reporting services based reports in either SharePoint or directly from the http://myserver/reports interface.

During the installation I had verified I had the correct password for my [domain]\tfsreports account used to run the reports. If went to the http://myserver/reports page and edited the TFS2010ReportsDs or TFS2010OlapReportDS and tried to test the [domain]\tfsreports login it failed. However, if I swapped to the [domain]\administrator all was fine and my reports worked.

So what was the issue?

The key point is that the server, as it is a PDC, would only allow limited accounts to login to the server console. The actual Reporting Services web services were running as a named domain account (you cannot use Network Service and like on a PDC), but it seems that the connection by the [domain]\tfsreports account is considered the same as a login via the login screen as far as security systems are concerned.

The immediate fix was to make sure the [domain]\tfsreports user was in a group listed in the “Allow log on locally". To check this

1. Run gpedit.msc
2. Expand Computer Configuration\Windows Settings\Security Settings\Local Policies
3. Click on User Rights Assignment
4. Ensure that "Allow log on locally" includes user required, or that the user is in one of the listed groups

Now I am not sure this is the end of story, I am sure I can waste loads of time to find out exactly the minimum security settings needed, but this is an adequate solution for no for me.

I posted a while ago about common confusion I had seen with Lab Management. We I have recently managed to get myself completely confused whilst working with Lab Management. It turns out the issue was so obvious I managed to miss it for hours, but as usual I learnt a good deal whilst trying to troubleshoot my stupidity.

I have a Lab Management system linked up to a a Team Project Collection (TPC). In this TPC there is a Team Project used for SharePoint development and on my Lab Management system I have an environment to allow testing of the SharePoint products. I setup a new Team Project in this TPC. In the new project I created a new MVC solution and created an automated build, which all worked fine.

I wanted to deploy this MVC application to a web server in an environment in my Lab Management system. So I created a basic web server environment and deployed it onto a host in my Lab. I then tried to create a Lab Management workflow build to deploy to the newly created environment. However the combo to select the environment was empty when I ran the wizard.

I was confused, I knew I had an environment on the Lab Management system, I had just created it in Test Manager (MTM) I could attach to it in MTM or Remote Desktop.

So I checked again

• that the TPC was correctly registered with Lab Management
• the environment was running in MTM
• that all the configuration for the Team Project looked OK via TFSLABCONFIG.EXE

All to no avail. Then after far too long I realised I was not looking at the same things in MTM and Visual Studio.

When you are in the Lab Center (green border) pages of MTM there is no obvious indication of the Team Project you are using. I had forgotten this and got it into my head I was looking at all the environments and libraries for my whole TPC. THIS IS NOT THE CASE. The environments and libraries are Team Project specific and not TPC specific. I had created my new environment in my SharePoint team project not in my new MVC one.

To swap Team Project I needed to change to the Testing Centre (blue border) view and change the Test Plan (top right)

to get the dialog to change the Team Project.

Once this is done you can go to the Lab Center again and you see the environments for the selected Team Project. This was where I needed to create my environment.

At this point you will notice that all the templates and VMs you imported into the other Team project are not in this one. You have to reimport them from SCVMM and then create the environments in MTM for that Team Project

To the technical tip here is remember that Lab Center in MTM is Team Project specific – NOT Team Project Collection specific, but it does its best to not remind you of this fact so it is easy to forget.

IIS Express is a great addition to the tools for .NET web developers; it allow a slightly cut down copy of IIS 7.5 to be run without administrative privileges on a developer’s PC. This means we can hopefully get away from the problems associated by either

1. Using Cassini – which is not IIS and does not do any clever
2. Using full IIS which means Visual Studio has to run as administrator to debug it and also causes source control issues when a project is shared between multiple developers (their IIS setup must match up)

If you install Visual Studio 2010 SP1 and IIS express you now get a new option, that is to use IIS express as your web server. This, via a few clicks, can be configured for SSL and should address 90%+ of the needs of most developers. Once a project is set to use IIS express the key properties are set via the VS Property windows

However you are not limited to only editing these options; but to do more you need to use some command line tools.

What I wanted to do

My problem was that I wanted to test a Windows Phone 7 application that used a WCF web service. If I switched the WCF project to use IIS Express the WP7 application could not access the web server as, for security reasons, IIS Express is by default limited to only responding to requests from the localhost. The WP7 application is on another device (or at least a VM for development), so its request are not handled.

So we need to enable remote access to the server. ScottGu said this can be done in his post about IIS Express, but not how to do it.

Also I wanted to test my WP7 application using HTTPS. This raised a second issue. By default IIS express uses a self signed certificate. When this is used the WP7 WCF client throws as error as it cannot validate the certificate. I needed to swap the certificate for a ‘real one’. Again ScottGu’s post says it can be done but not how.

How I got it working

NOTE: I think the process covers all the steps, but it took me a while to get this going so there is a chance I might have missed step. Please treat this as outline guide and not definitive way to get it going. if I find errors I will update the post and highlight them.

Step 1 – Get the right Certificate onto the Development PC

I had already installed  the wildcard SSL certificate we have on my development PC from ita .PFX file.

To confirm this was OK I load MMC (running as a local administrator). Loaded the certificates snap-in, browsed to Personal|Certificates and checked it was there. I then clicked on the certificate and made a note of its thumbprint, you need it later

Step 2 – List the certificates you have installed for IIS

I opened a command prompt as administrator and run the command

netsh http show sslcert

This will stream past so you probably want to pipe it into a file to look at. Anyway you should find an entry for the self sign certificate that Visual Studio created when you setup IIS Express (on port 44300 in my case). Something like

IP:port                 : 0.0.0.0:44300
    Certificate Hash        : c3a234250edfb2adcd2b501cf4c44d0281e29476
    Application ID          : {214124cd-d05b-4309-9af9-9caa44b2b74a}
    Certificate Store Name  : MY
    Verify Client Certificate Revocation    : Enabled
    Verify Revocation Using Cached Client Certificate Only    : Disabled
    Usage Check    : Enabled
    Revocation Freshness Time : 0
    URL Retrieval Timeout   : 0
    Ctl Identifier          : (null)
    Ctl Store Name          : (null)
    DS Mapper Usage    : Disabled
    Negotiate Client Certificate    : Disabled

We need to remove this self signed certificate so we can re-assign a real one to this port. To do this use the command

netsh http delete sslcert ipport=0.0.0.0:44300

then add the new certificate association using the command

netsh http add sslcert ipport=0.0.0.0:44300 certstorename=MY certhash=<certificate hash> appid=<appid>

<certificate hash> is the thumbprint of the SSL certificate found in step 1, with the spaces removed
<appid> can be any unique GUID

if you have the command line right it should say added OK. You could then run the list command again to check it is as you want.

So where are we up to…..

So at this point we have associated a real SSL certificate with any call to the port 44300 on this PC, note any call to this port, not just for IIS Express. If we do nothing else to configure IIS Express, let Visual Studio automatically start it, and try to load the site it will work for HTTP but when you try HTTPS it will error

If you inspect the certificate you will see it is using the one you set, but the certificate is linked to a Url, in my case *.blackmarble.co.uk so is deemed invalid when you try to use it with localhost.

We need to set IIS Express to respond on other addresses than localhost.

Step 3 – Making IIS Express respond to requests from the network

If you wish to make IIS Express respond to calls other than for localhost you have to run it as administrator, this is by design for security. Now it is fair to say from here onwards you are at the point where you lose some of the ease of use of the product as it does not ‘just work form Visual Studio’, but needs must.

We now need to edit the bindings of IIS Express. This could be done with command

c:\program files\iis express>appcmd set site "SiteName" /+bindings.[protocol='https', bindingInformation='*:44300:']

But I found it easier just to edit the edit the file C:\Users\[user name]\Documents\IISExpress\config\applicationhost.config in notepad. I altered the bindings section as follows

<bindings>
      <binding protocol="http" bindingInformation="*:60213:" />
      <binding protocol="https" bindingInformation="*:44300:" />
</bindings>

Basically I removed the :localhost at the end of each line. This allowing IIS Express to bind any Url not just localhost

Step 4 – Running IIS Express

You now need to just start your copy of IIS Express, this again has to be done from the command prompt running with administrative privileges. However, the command line parameters are identical to those used by Visual Studio (you can check task manager if you wish by showing the command line column on the processes tab)

"c:\Program Files (x86)\IIS Express\iisexpress.exe" /config: "c:\Documents and Settings\[username]\Documents\IISExpress\config\applicationhost.config" /site:"MyServer" /apppool:"Clr4IntegratedAppPool"

When you run this you should see the IIS Express process start-up.

So what have we ended up with?

So we now have IIS Express running the a wildcard certificate and listening to requests from any source. So as long as we use a Url valid for the SSL certificate we should be be able to load an HTTPS Url and get no errors.

However, be warned, due to the way we have had to launch IIS Express we have lost the ability to launch and debug from Visual Studio when not running as administrator. So I am not sure I have addressed the problem I started out try to address, I might as well just use the full version of IIS.

But look on the bright side I learnt something.

Thanks to Andy Westgarth for his assistance in getting to the bottom of assigning the right certificate, I was going in circles

I got round to installing Visual Studio 2010 SP1 on my laptop last night; well I started last night via the Web Platform Installer method. It downloaded the bits fast but sat for ages on the first step, installing the actual service pack. There was no obvious activity on the CPU or disk. In the end I gave waiting and went to bed. I was pleased to see it was finished this morning.

So the tip here is be patient, applying this service pack is a job you start on your desktop before you go home, not when you come into the office.

So what is the biggest benefit thus far?

I can easily use IIS Express from with Visual Studio, so no more having to run Visual Studio as administrator to us my local IIS Server for development.

If you try to create an automated TFS build of a Windows Phone 7 Silverlight application on a ‘default installed’ build agent you will see errors along the lines of

The imported project "C:\Program Files\MSBuild\Microsoft\Silverlight for Phone\v4.0\Microsoft.Silverlight.WindowsPhone.Overrides.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

This is because the PC your build agent is running on does not have the WP7 SDK installed.

Simple you would think, lets just install the SDK. Well, if your build box is based on any Windows Server operating system you quickly hit a problem that you get the error the “Windows 7 or Windows Vista is required”

There is no supported route around this, but there is a hack. The fix is to follow the UNSUPPORTED process on Aaron Stebner's blog. This edits the baseline.dat from the installation media to make, in my case, Windows Server 2008 a supported operating system. Once this was done the SDK could be installed and automated builds run.

As usually, as this is unsupported, it is buyer beware, try it at your own risk.

I am doing some work on VS2008 at present and I when I started my VS2008, which I had not used for a while, I was plagued by errors along the lines of "The operation could not be completed". These occurred when running major features such as:

• Loading LINQ to SQL Designer
• Running the SQL 2008 Project Wizard

The fix turned out to be resetting the package skip loading flag. It seems a number of add-ins were not being loaded on startup. This command is run from the "Visual Studio 2008 Command Prompt" by typing

devenv /resetskippkgs

I also had problems trying to run tests using the standard Microsoft Test tools within Visual Studio. I got the error “Exception has been thrown by the target of an invocation”, but running tests using TestDriven.NET worked fine. This problem was not fixed with the /resetskippkgs. However, turns out it is a known issues if VS2008 SP1 and TFS, KB980216. The quick fix is to make sure I was connected to a TFS server. Once this was done the test could be run. There is a hotfix, but I can live without I think for now.

So the moral is, even if you don’t use an IDE everyday you can still break it with all the patching you do around it for other IDEs and underlying frameworks. A reset to defaults can often by just the kick it needs to get it working.

Whilst doing some tidying on a multi-server TFS 2010 system I needed to move a team project collection from one Application Tier (AT) to another. Both ATs (which were not a load balanced pair) shared the same SQL server data tier (DT). It should have been easy using the TFS Administration Console.

I backed up the TPC database using SQL Management tools, the TPC was then detached without any issue from the first AT. I then backed up the SQL DB again in the detached state.

I then I tried to attach the TPC on the second AT. I entered the SQL DT instance name to get a list of TPCs available for attachment and I got the error

TF30040: The database is not correctly configured.
Contact your Team Foundation Server administrator.

So I went back to the original AT and tried a re-attach and got the same error message. Strange I had not changed accounts, the TFSSetup account in use had enough rights to detach the collection but not list one to be attached, strange!

A quick chat with the DBA found the problem, the TFSSetup account in use on both ATs had had its rights trimmed on the SQL server since the system was installed. As soon as it was granted admin rights to the SQL server all was fine with the listing TPCs available for attachment and the actually attaching the TPC on the new server.

Though I did not try it I suspect that as soon as I had the list of available TPCs in the TFS Administration Console I could have removed the extra SQL rights. The TFSService account would be doing the actual attachment, as it had done the detach, the TFSSetup account only need to be used to list the available TPCs.

When loading an ASP.NET 3.5 web application that has been compiler for Any CPU onto an IIS7 server I got the error

The 'Microsoft.Jet.OLEDB.4.0' provider is not registered on the local machine.

This was because the server was running a 64bit OS and only the 32bit Access Driver was installed. The quick fix to get this running was to enable 32-bit applications on the AppPools advanced settings.

The TFS Integration Platform is an ALM Rangers project that provides an excellent set of tools to migrate or synchronise source code and/or work items between different TFS servers or TFS server and third party platforms. For many people the supported release on Code Gallery will do all they need. However if you have a need to connect to a system that there is no adaptor for you need the Codeplex version so you can write it yourself. To get the environment up and running, not unsurprisingly, the best place to start is the Getting Started documents.

I did this, I got all the pre-requisites (or so I thought), I download the code and unpack the zip. I ran the  extract_tfs_assemblies.bat to get the local copies of the TFS API assemblies and loaded the MigrationTools.sln in VS2010.

First thing I noted was that I was asked to convert the solution and project files to 2010 format, though they appeared to be the right format to start with. I did this but the report showed no changes, strange!

On loading the solution, other than the ‘TFS offline’ dialog the instructions mention, it also reported it could not load the InstallationCS.csproj file because

C:\Projects\ITIS\IntegrationPlatform\Setup\InstallationCA\InstallationCA.csproj(133,3): The imported project "C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.5\Wix.CA.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

The Wix directory for the current distribution is C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x, a quick edit of the InstallationCA.csproj in notepad to correct the path fixed this load problem (wonder if that was why VS2010 though it needed to do a solution upgrade?, I could not be bother to roll back to find out.)

I then tried to build the solution, and got around 150 errors, starting with the error

C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(292,5): error MSB8009: .NET Framework 2.0/3.0/3.5 target the v90 platform toolset. Please make sure that Visual Studio 2008 is installed on the machine.

I checked and this targets file was there. I had VS2010 and VS2008 installed what could be the problem?

Well it turned out that though I had VS2008 installed I had (for some strange reason lost in the mists of time) not selected the C++ components. Easy to fix you would think. Just go into control panel, into installed products and add the missing features, so I tried to add C++ and got the message

A selected drive is no longer valid. Please review your installation path settings before continuing with setup

I tried inserting DVDs, mounting ISO etc. all to no avail. The found on this forum post, turns out you have to remove VS2008 SP1, add the feature and then re-patch.Once this was done I could build the C++ projects.

As a side note here, I went through this process a couple of time, the first time I also managed to get the TFS adaptor projects references a bit confused. The TFS2008 adaptor projects had ended up referencing the TFS2010 assemblies. This caused a build error due to obsolete calls. This was easily fixed by repointing the references to the copies of the assemblies the extract_tfs_assemblies.bat creates. However if you remember to run extract_tfs_assemblies.bat before opening the solution for the first time this should not be an issue, as all the right assemblies will be on the correct hint paths.

So I now had 36 build errors. The next one I tackled was

Unable to copy file "C:\Projects\ITIS\TestEnv\MigrationTestEnvironment.xml" to "..\..\..\Binaries\Debug\\Test\MigrationTestEnvironment.xml". Could not find a part of the path 'C:\Projects\ITIS\TestEnv\MigrationTestEnvironment.xml'.    MigrationTestLibrary

This  was because the file was actually missing, it is not under the Codeplex source control. This is the XML file defines the adaptors under test. You need to create it based on the test you wish to run, or that is my current understanding. To get around the error (as a start) I just set it ‘copy to output directory’ property to ‘do not copy’ – knowing I would switch this back later

I was now down to 16 errors, all related to the Subversion related projects. These requires, fairly obviously, some Subversion libraries I did not have on my PC. As I did not need to work with Subversion I could have chosen to just remove these projects from the solution, but I thought why not fix it it all. They key again was to follow the readme.txt in the Interop.Subversion project folder. You need to download and unzip the two sets of source for Subversion and Apr.

I was then left with a missing reference to SharpSvn. This I downloaded from http://www.open.collab.net/files/documents/180/2861/SSvn-1.6006.1373.zip and unpacked to the {solution root}/binaries/external/sharpsvn  and made sure the SubversionTCAdapter project reference pointed to this location.

Once all this was done all the projects in the solution built. So nothing too complex really, especially when you follow the instructions in the right order!

So to develop some custom adaptors now then……