But it works on my PC!

The problem

I have been working on a project that contains SharePoint 2010 WSP packages and a MSI distributed WPF application. These projects are all in a single solution with their unit tests. I have been getting a problem with our TFS 2012.2 build system, all the projects compile but at the test point I get the unhelpful

TF900546: An unexpected error occurred while running the RunTests activity: 'Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.'.

If I remote onto the build box and loaded the solution in Visual Studio (which was luckily installed on the build box) and tried to run the test in the test explorer I got

and the event log showed

Application: vstest.executionengine.x86.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.InvalidProgramException
Stack:
   at System.ServiceModel.ServiceHost..ctor(System.Object, System.Uri[])
   at Microsoft.VisualStudio.TestPlatform.TestExecutor.TestExecutorMain.Run(System.String[])
   at Microsoft.VisualStudio.TestPlatform.TestExecutor.ServiceMain.Main(System.String[])

and

Faulting application name: vstest.executionengine.x86.exe, version: 11.0.60315.1, time stamp: 0x5142b4b6
Faulting module name: KERNELBASE.dll, version: 6.1.7601.18015, time stamp: 0x50b83c8a
Exception code: 0xe0434352
Fault offset: 0x0000c41f
Faulting process id: 0x700
Faulting application start time: 0x01ce4663824905bd
Faulting application path: C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 11.0\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\TESTWINDOW\vstest.executionengine.x86.exe
Faulting module path: C:\Windows\syswow64\KERNELBASE.dll
Report Id: c2689d15-b256-11e2-80aa-00155d0a5201

Next I tried creating in a simple new test project with one unit test, this failed with the same error.

As all the tests work locally on my development PC it was all pointing to a corrupted installed of Visual Studio (and/or the components installed as part of TFS build) on the build box. It should be noted that this was a build box with a good number of additional packages installed to support SharePoint, so patching order could be an issue.

The workaround

Robert, another of our ALM consultants, said he had seen a similar problem at client and suggested changing the test runner.

So in the build definition > process > Basic > Automated Tests > I edited the test run settings and changed to the MSTest VS2010 runner from the default.

Once this was done my tests then ran. However I then got a publishing error

API restriction: The assembly 'file:///C:\Builds\2\BM\CTAppBox.Main.CI\Binaries\_PublishedWebsites\WebServiceTestClient\bin\WebServiceTestClient.dll' has already loaded from a different location. It cannot be loaded from a new location within the same appdomain.

The problem was the build was set to the default test search criteria of *test*. This meant it picked a project it should not have, due to a poor naming convention. As soon as I changed the filter to *.tests all was OK.

I did retry the VS2012 test runner after fixing this naming issue, it had no effect.

I know I need to sort (rebuild) this build box, but now is not the time, I have a working solution that will do for now

I have been trying to get SQL 2012 SSIS packages built on a TFS2012.2 build system. As has been pointed out by many people the problem is you cannot build SQL SSIS packages with MSBuild. This means you have to resort to call Visual Studio DevEnv.exe from within your build.

Jakob Ehn did a great post on this subject, but it is a little dated now due the release of VS 2012 and SQL 2012

The command line

But before we get to TFS, let us sort the actual command line we need to run. So assume VS2012 is in use, the basic command line build for a solution will be

“C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv”  “MySolution.sln” /build "Release|Any CPU"

If you solution only contains SSIS packages then this command line might be OK. However you might just want to build a single SSIS project within a larger solution. In this case you might use

“C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv”  “MySolution.sln” /build "Release|Any CPU"  /project “SSISBits\SSISBis.dtproj”

So to work out the command line you need,  first you need to make sure VS2012 and the Business Intelligence tools are installed on your build box. Once this is done you can try the command line. I decided for my project that I would create a second solution file in the root of the source code that just contained my two SSIS projects, thus making the command line easier (basically one solution for SSIS packages and another for everything else).

So I ran the command line

“C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv”  “MySolution.sln” /build "Release|Any CPU"

and got

Microsoft (R) Microsoft Visual Studio 2012 Version 11.0.60315.1.
Copyright (C) Microsoft Corp. All rights reserved.
Error: Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED))
Error: Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED))
========== Build: 0 succeeded or up-to-date, 2 failed, 0 skipped ==========

Not good. So I checked that if I loaded the same solution in the same copy of Visual Studio 2012.2 it built OK, and it did.

So it seems there is an issue with command line build of SSIS packages in VS2012. A quick search showed it was a logged issue on Microsoft Connect. Luckily a workaround was mentioned, so I tried it, to use the VS2010 version of the tools. So my command line became

“C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv”  “MySolution.sln” /build "Release|Any CPU"

To try this I had to install the SQL Data Tools from my SQL 2012 ISO (not the SSDT tools from the web as these free ones don’t have the BI features). Once this had installed I could issue my command line and it all built OK.

So I knew I had a working command line. I started to put the same version of VS2010 SSDT tools on my TFS build box and moved onto the build process.

The TFS Build Process

So as now I had the command line, I could apply this knowledge to the process Jakob outlined. There are two basic steps

1. Run the command line build – this was basically the same
2. Find the files created and copy them to the drops location – the change here is the old post mentions .MSI files, now we are looking for .ISPAC files

As I had decided to have two solutions within my build, I used an if block (based on a solution name convention) to choose if needed to do a MSBuild or DevEnv build. So my process flow for the build phase was.

Also I had to edit the xcopy block to look for .ISPAC files extensions i.e.

Other than these changes the templates was exactly as Jakob described – even down to using VS2010!

Summary

So once all this was done I had a build that create my SSIS packages.

All seems a lot of work, life would be so much easier if SSDT

• Work properly under VS2012
• Or even better support MSBuild!

Using the Typemock TFS 2012 Build activity I created I had started seen the error

TF900548: An error occurred publishing the Visual Studio test results. Details: 'The following id must have a positive value: testRunId.'

I thought it might be down to having patched our build boxes to TFS 2012 Update 1, maybe it needed to be rebuild due to some dependency? However, on trying the build activity on my development TFS server I found it ran fine.

I made sure I had the same custom assemblies and Typemock autorun folder and build definition on both systems, I did, so it was not that.

Next I tried running the build but targeting an agent not on the same VM as the build controller. This worked, so it seems I have a build controller issues. So I ran Windows update to make sure the OS was patched it to date, it applied a few patches and rebooted. And all was OK my test ran gain.

It does seem that for many build issues the standard switch it off and back on again does the job

I have been battling setting up a DB deployed via the SQL 2012 DAC tools and Powershell.  My environment was a network isolated pair of machines

• DC – the domain controller and SQL 2012 server
• IIS – A web front end

As this is network isolated I could only run scripts on the IIS server, so my DB deploy needed to be remote. So the script I ended up with was

param(
    [string]$sqlserver = $( throw "Missing: parameter sqlserver"),
    [string]$dacpac = $( throw "Missing: parameter dacpac"),
    [string]$dbname = $( throw "Missing: parameter dbname") )

Write-Host "Deploying the DB with the following settings"
Write-Host "sqlserver:   $sqlserver"
Write-Host "dacpac: $dacpac"
Write-Host "dbname: $dbname"

# load in DAC DLL (requires config file to support .NET 4.0)
# change file location for a 32-bit OS
add-type -path "C:\Program Files (x86)\Microsoft SQL Server\110\DAC\bin\Microsoft.SqlServer.Dac.dll"

# make DacServices object, needs a connection string
$d = new-object Microsoft.SqlServer.Dac.DacServices "server=$sqlserver"

# register events, if you want 'em
register-objectevent -in $d -eventname Message -source "msg" -action { out-host -in $Event.SourceArgs[1].Message.Message } | Out-Null

# Load dacpac from file & deploy to database named pubsnew
$dp = [Microsoft.SqlServer.Dac.DacPackage]::Load($dacpac)
$d.Deploy($dp, $dbname, $true) # the true is to allow an upgrade, could be parameterised, also can add further deploy params

# clean up event
unregister-event -source "msg"

Remember the SQL 2012 DAC tools only work with PowerShell 3.0 as they have a .NET 4 dependency.

This was called within the Lab Build using the command line

cmd /c powershell $(BuildLocation)\SQLDeploy.ps1 dc $(BuildLocation)\Database.dacpac sabs

All my scripts worked correctly locally when I ran it on the command line, they were also starting from within the build, but failing with errors along the lines of

Deployment Task Logs for Machine: IIS
Accessing the following location using the lab service account: blackmarble\tfslab, \\store\drops.
Deploying the DB with the following settings
sqlserver:   dc
dacpac: \\store\drops\Main.CI\Main.CI_20130314.2\Debug\Database.dacpac
dbname: Database1
Initializing deployment (Start)
Exception calling "Deploy" with "3" argument(s): "Could not deploy package."
Initializing deployment (Failed)
At \\store\drops\Main.CI\Main.CI_20130314.2\Debug\SQLDeploy.ps1:26
char:2
+  $d.Deploy($dp, $dbname, $true) # the true is to allow an upgrade
+  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : DacServicesException
Stopped accessing the following location using the lab service account: blackmarble\tfslab, \\store\drops.

Though not obvious from the error message the issue was who the script was running as. The TFS agent runs as a machine account, this had no rights to access the SQL on the DC. Once I granted the computer account IIS$ suitable rights to the SQL box all was OK. The alternative would have been to enable mixed mode authentication and user a connection string in the form 

“server=dc;User ID=sa;Password=mypassword”

So now I can deploy my DB on a new build.

Today has been one of purging build system problems. On my TFS 2012 Windows 8 build box I was was getting the following error when trying to run Windows 8 App Store unit tests

TF900546: An unexpected error occurred while running the RunTests activity: 'Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.'.

On further investigation, I am not really sure anything was working too well on this box. To give a bit of background

• I have one build controller build2012
• with a number of build agents spread across various VMs. I use tags to target the correct agent e.g. SUR40 or WIN8

In the case of Windows 8 builds (where the  TFS build agent has to run on a Windows 8 box) the build seemed to run, but tests failed with the TF900546 ‘its broken error, but I am not saying why’ error. As usual there was nothing in the logs to help.

To try to debug the error I added a build controller to this box, and eventually, just like Martin in his post noticed, after far too long, that I was getting a error on the build service on the Windows 8 box and the agent was not fully online.

The main symptom is the build agent says ready, but shows a red box (stopped). If you hit the details link that appears you get the error dialog. Martin had a 500 error, I was getting a 404. I had seen similar problems before, I really should read (or at least remember) my own blog posts.

I can’t stress enough, if you don’t see a green icon on build controllers and agent you have a problem, it might not be obvious at that point but it will bite you later!

For me the fix was the URL I was using to connect to the TFS server. i was using HTTPS (SSL), as soon as switched to HTTP all was OK. In this case this was fine as both the TFS server and build box were in the same rack so SSL was not really needed. I suspect that the solution, if I had wanted SSL, would be as Martin outlined, a config file edit to sort out the bindings.

But remember….

That having a working build system is not enough for Windows 8 App Store unit tests. You also have to manually install the application certificate for test assembly as detailed in MSDN as well as getting the build service running in interactive mode.

Once this was done my application build and the tests ran OK

A while ago I posted about seeing the TF900546 error when running unit tests in a previously working TFS 2012 build. The full error being:

TF900546: An unexpected error occurred while running the RunTests activity: 'Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.'.

Well late last week this problem came back with avengeance on a number of builds run on the same build controller/agent(s). Irritatingly I first noticed it after a major refactor of a codebase, so I had plenty of potential root causes as assemblies had been renamed and it was possible they might not be found. However, after a bit of testing there were no obvious candidates as all tests worked fine locally on my development PC, and a new very simple test application showed the same issues. It was defiantly an issue on the build system.

I can still find no good way to debug this error, Stackoverflow mention Fuslogvw and WinDbg, as well as various copy local settings and the like. Again all seems too much as this build was working in the past, just seemed to stop. I tried a couple but got no real information, and the error logs were empty.

In the end I just tried what I did before (as I could think of no better tactic to pin down the true issue). I went into the build controller config, removed the reference to the custom assemblies, saved this settings (causing a controller restart), then put it back (another restart of the controller)

After this my test started working again, with no other changes

Interesting a restart of VM running the build controller did not fix the problem. However this does somewhat chime with comments in the StackOverFlow thread that causing the AppPool in MVC apps to rebuild completely, ignoring any cached assemblies, seems to fix the issue.

A video has just be uploaded that I did on the new unit testing features in Visual Studio  and TFS 2012. This is quick 10 minute introduction to some of the material I will be covering at DDDNorth next weekend.

Hope you find it useful

I posted last week on the problems I had had getting the test agents and controller in a TFS2012 Standard environment talking to each other and a workaround. Well after a good few email with various people at Microsoft and other consultants at Black Marble I have a whole range of workarounds solutions.

First a reminder of my architecture, and note that this could be part of the problem, it is all running on a single Hyper-V host. Remember this is a demo rig to show the features of Standard Environments. I think it is unlikely that this problem will be seen in a more ‘realistic’ environment i.e. running on multiple boxes

The problem is that when the test agent running on the Server2008 should request the test controller (running the on VSTFS server) should call it back on either it 169.254.x.x address or on abn address obtained via DHCP from the external virtual switch. However the problem is it is requesting a call back on 127.0.0.1, as can be seen in the error log

Unable to connect to the controller on 'vstfs:6901'. The agent can connect to the controller but the controller cannot connect to the agent because of following reason: No connection could be made because the target machine actively refused it 127.0.0.1:6910. Make sure that the firewall on the test agent machine is not blocking the connection.

The root cause

It turns out the root cause of this problem was I had edited the c:\windows\system32\drivers\etc\hosts file on the test server VM to add an entry to allow a URL used in CodedUI tests to be resolved to the localhost

127.0.0.1   www.mytestsite.com

Solution 1 – Edit the test agent config to bind to a specific address

The first solution is the one I outlined in my previous post, tell the test agent to bind to a specific IP address. Edit

C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\QTAgentService.exe.config

and added a BindTo line with the correct address for the controller to call back to the agent

<appSettings>
     // other bits …
      <add key="BindTo" value="169.254.1.1"/>
</appSettings>

The problem with this solution you need to remember to edit a config file, all seems a bit complex!

Solution 2 – Don’t resolve the test URL to localhost

Change the hosts file entry used by the CodedUI test to resolve to the actual address of the test VM e.g.

169.254.1.1   www.mytestsite.com

Downside here is you need to know the test agents IP address, which depending on the system in use could change, and will certainly be different on each test VM in an environment. Again all seems a bit complex and prone to human error.

Solution 3 – Add an actual loopback entry to the hosts file.

The simplest workaround which Robert Hancock at Black Marble came up with was to add a second entry to the hosts file for the name loopback

127.0.0.1   localhost
127.0.0.1   www.mytestsite.com

Once this was done the test agent could connect, I did not have to edit any agent config files, or know the address the agent need to bind to. By far the best solution

So thanks to all who helped get to the bottom of this surprisingly complex issue.

I posted a while ago that you saw errors when trying to edit TFS 2012RC build process templates in VS 2012RC if the Visual Studio class library project you were using to manage the process template editing was targeting .NET 4.5, it needed to be 4.0. Well with Visual Studio 2012 RTM this is no longer the case, in fact it is the other way around.

I have recently upgraded our TFS 2012 RC –> RTM and I today came to edit one of our build process templates (using the standard method to edit a process template with custom activities) and got the following error when I tried to open the XAML process template for editing

System.Xaml.XamlException: 'The type ‘InArgument(mtbwa:BuildSettings)’ of property ‘BuildSettings’ could not be resolved.' Line number '3' and line position '38'.

At first I assumed it was my custom activities, so I tried editing the DefaultTemplate.11.1.xaml in the same manner, but got the same problem.

Strangely I found that if I had no solution open in Visual Studio then I could just double click on the DefaultTemplate.11.1.xaml file in Source Control Explorer and it opened without error. However, if I had a solution open in the same instance of VS2012 that contained a class library project that linked to the same XAML file I got the error. Unloading the project within the solution allowed me to open the file via Source Control Explorer, reloading the project again stopped it loading.

So it all pointed to something about the containing class library project stopping referenced assemblies loading. On checking the project properties I saw that it was targeting .NET 4.0 (as required for the RC), as soon as I changed this to .NET 4.5 it was able to load all the required Team Foundation assemblies and I was able to edit both the default template and my custom build process template.

Whilst moving over to our new TFS 2012 installation I got the following error when a build tried to run tests

TF900546: An unexpected error occurred while running the RunTests activity: 'Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.'.

This was a new one on me, and nothing of much use on the web other than a basic MSDN page.

Turns out the immediate fix is to just restart the build controller. Initially I did this after switching to the default build process template, and setting it to NOT load any custom activities, but I seems a simple restart would have been enough as once I re-enabled all custom activities it still worked.

As to the root cause I have no idea, one to keep an eye on, especially as I am currently on the RC, lets see what the RTM build does.