Robert Hancock's Blog

It’s been a while since I have used PowerShell on a client operating system. I have been running Windows 8 for a while now, but have not needed to use Powershell. I wanted to write a small Powershell and thought I would use the ISE (Integrated Scripting Environment) provided by Microsoft. I was surprised to find that when i hit the Windows key and searched for Powershell, the console appeared but nothing appeared for the ISE.

I thought it must be that I needed to enable a Windows feature or download it from Microsoft. Before trying both of those options I decided to fire up an instance of PowerShell and see if i could launch the ISE.

Which did launch the ISE for me.

As a shortcut if i type ‘Powershell ise’ in the start search box it will launch an instance of Powershell and execute the command to launch the ISE.

Update 17/12/2012: Neno has now published his official 2012 version. The .exe can be found here

A number of our customers use the TfsSyncIdentities tool by Neno Loje. When running the TfsSyncIdentities on a 2012 instance the following error appeared:

I fired up an instance of ILSpy to try to understand what the application was doing. It turns out that the application is using a service reference to call to the JobService web service.

My guess was that the web service had changed in some way in 2012. I created a new console application in visual studio and copied the code from the Main method disassembled in ILSpy and placed it in my application. I then added a service reference to http://TFS:8080/tfs/TeamFoundation/Administration/v3.0/JobService.asmx. Once I added the required references, I had to change the following method call from:

   1: jobWebServiceSoapClient.QueueJobsNow(new Guid[]  

   2: {  

   3: Guid.Parse("544dd581-f72a-45a9-8de0-8cd3a5f29dfe")  

   4: }, true);]

To

   1: jobWebServiceSoapClient.QueueJobs(new Guid[]

   2: {  

   3: Guid.Parse("544dd581-f72a-45a9-8de0-8cd3a5f29dfe")  

   4: },true, 0);

Hit F5 and you should have a TfsSyncIdentities application that works with TFS 2012. When run against a 2010 instance the sync still ran successfully with the new version of the application.

After updating my local test instance of TFS2010 to service pack 1 I came across the following error when trying to connect to a team project collection:

I launched the TFS Administration Console and selected the Default Collection from the Team Project Collections section, my first thought was to try stopping and starting the Default Collection. After shutting down the Team Project Collection I noticed under the status tab ‘Servicing Collection’ job had been queued for  some time for the Team Project Collection.

I launched services manager and found that the Visual Studio Team Foundation Background Job Agent was disabled. I enabled this service and rerun the job. After a minute or so the job changed from queued to success. Ensuring the Team Project Collection was back online I was able to successfully connect to the Team Project Collection.

For testing and demonstrations I have a basic installation of TFS2010 installed on my Windows 7 boot. Whist demonstrating the branching within TFS to a customer I came across an error when attempting to branch a folder by label:

Branching by label is something I do frequently in our production TFS environment so I was confident the issue had to be with my local TFS instance. After a quick search online one of the many suggestions relating to this error was a mismatch between versions of TFS 2010 and Visual Studio 2010. After checking the version of both products I found I had patched Visual Studio 2010 to service pack 1, however as my TFS installation was only for testing I had not ensured that the patch level was up to date.

Once I installed service pack 1 for TFS2010 I was able to branch a folder by a label successfully.

If you use Visual Studio Database Projects you may be familiar with the VSDBCMD utility to control the deployment of a database project.

Whilst testing a custom Team Foundation Server 2010 build template which included an activity to deploy a database project using the VSDBCMD, I came across the following error:

*** The target database schema provider could not be determined. Deployment cannot continue.

After looking into the error it turned out that the SQL Instance name in the connection string was incorrect. After resolving this issue the database project deployed to the SQL Instance as expected.