But it works on my PC!

The random thoughts of Richard Fennell on technology and software development

‘Expected to find an element’ error when running VS2010 Database unit tests

If you use the database unit testing feature of VS2010 there is a good chance you will want to run these tests on more than one PC and probably the build server. The issue is that these different PC will need different deployment paths and SQL connection strings. Luckily there is a feature to address this, as detailed on MSDN. Basically the test runner swaps in a different config file based on either the PC name or user running the tests.

This all seems straight forward, but when I followed the process and ran my tests they failed

image 

The most useful error is found if you get the test run details (the button highlighted in green). You can see that it found the file replacement config file but failed to parse it giving the error

An error occurred while reading file C:\…\TestResults\fred_PCNAME 2011-09-12 22_33_11\Out\buildbox.dbunittest.config : Expected to find an element.

[It is work noting here it is easy to forget to make sure the buildbox.dbunittest.config is deployed to the test folder as detailed on MSDN. If you forget this you get a file not found error not an ‘expected to find an element’ error]

So I checked my buildbox.dbunittest.config file to look for typos. The MSDN instructions say to copy the app.config and make your edits, but then goes onto mention after editing it should resemble.

<DatabaseUnitTesting> 
       <DatabaseDeployment DatabaseProjectFileName="..\..\..\Sources\UnitTest\UnitTest\UnitTest.dbproj" Configuration="Debug" />
       <DataGeneration ClearDatabase="true" />
       <ExecutionContext Provider="System.Data.SqlClient" ConnectionString="Data Source=.\SQLEXPRESS;
                       Initial Catalog=UnitTestB;Integrated Security=True;Pooling=False" CommandTimeout="30" />
       <PrivilegedContext Provider="System.Data.SqlClient" ConnectionString="Data Source=.\SQLEXPRESS;
                       Initial Catalog=UnitTestB;Integrated Security=True;Pooling=False" CommandTimeout="30" />
</DatabaseUnitTesting> 

It should NOT include the <?xml version="1.0" encoding="utf-8" ?>, <configuration> or <configSections> tags. This as been stressed in some forum posts. However even when I made sure my buildbox.dbunittest.config first line was <DatabaseUnitTesting> I still got the same error.

Turns out the issue was that I had leading white space before the <DatabaseUnitTesting>, once these were removed the test ran as expected.

Update on using Typemock Isolator to allow webpart development without a Sharepoint server

I have in the past posted about developing SharePoint web parts without having to use a SharePoint server by using Typemock Isolator. This technique relies on using Cassini or IIS Express as the web server to host the aspx page that in turn contains the webpart. This is all well and good for SharePoint 2007, but we get a problem with SharePoint 2010 which seems to be due to 32/64bit issues.

Working with SharePoint 2007 assemblies when SharePoint 2010 assemblies are in the GAC 

I started this adventure with a SharePoint 2007 webpart solution setup as discussed in my previous post. In this solution’s web test harness I was only referencing the SharePoint 2007 Microsoft.Sharepoint.dll. This had been working fine on a PC that had never had SharePoint installed, the required DLL was loaded from a local solution folder of SharePoint assemblies.

This was until I installed SharePoint 2010 onto my Windows 7 development PC (a great way to do SharePoint development). This put the SharePoint 2010 assemblies into the GAC. So now when I ran my Sharepoint 2007 test harness I got the error

Description: An error occurred during the compilation of a resource required to service this request. Please review the following specific error details and modify your source code appropriately.
Compiler Error Message: CS1705: Assembly 'Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' uses 'Microsoft.SharePoint.Library, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' which has a higher version than referenced assembly 'Microsoft.SharePoint.Library, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c'

The solution is fairly simple, assuming you want work with the 2007 assemblies. All you need to do is make sure the test harness project also references the 2007 Microsoft.Sharepoint.library.dll so it does not pickup version in the GAC.

image

Once this is done the 2007 based test harness worked again

But what about using 2010 assemblies?

If you want to work against SharePoint 2010 assemblies there are other problems. If you just reference the 2010 Microsoft.sharepoint.dll you get the error

Could not load file or assembly 'Microsoft.Sharepoint.Sandbox' or one of its dependencies. An attempt was made to load a program with an incorrect format

As I said, on my PC I now have a SharePoint local installation, so I have the SharePoint 2010 assemblies in the GAC. It is from here the test harness tries to load the Microsoft.Sharepoint.Sandbox.dll assembly. The problem is that this is not a standard MSIL assembly but a 64bit one. The default Cassini development web server is 32bit. Hence the incorrect format error, the WOW64 technology behind the scenes cannot manage the loading. The only option is to use a 64bit web server to address the problem; so this rules out Cassini and IIS Express at this time as these are 32bit only.

A possible solution is to use the full IIS 7.5 installation available with Windows7, as this must be 64bit as it is able to run SharePoint 2010. The problem here is that when you load the test harness you get the error

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: TypeMock.TypeMockException:
*** Typemock Isolator is not currently enabled.
To enable do one of the following:
* To run Typemock Isolator as part of an automated process you can:
- run tests via TMockRunner.exe command line tool
- use 'TypeMockStart' tasks for MSBuild or NAnt
* To work with Typemock Isolator inside Visual Studio.NET:
set Tools->Enable Typemock Isolator from within Visual Studio
For more information consult the documentation (see 'Running' topic)

This is because this IIS instance is not under the control of Visual Studio and so it cannot start Isolator for you. To get round this you have to start Isolator manually, maybe you could do it in your test harness pages. However, you also have to remember that you if you want to debug against this IIS instance you must run Visual Studio as administrator – OK this will work, but I don’t like any of this. I really do try not to run as administrator these days.

So what we need is a 64bit web server. The best option appears to be http://cassinidev.codeplex.com. This can be used as a direct replacement for Cassini. This is still a 32bit build by default, but if you pull the source down you can change this. You need to change all the projects from x86 to Any CPU, rebuild and copy the resultant EXE and DLLs over the Cassini installation. I recommend you copy the 32bit release build over first to get the right .config files in place. You probably don’t want to use the ones from the source code zip.

Once this is all done you have a web server that can load 32bit and 64bits without issue. So for my test project I referenced the SharePoint 2010 assemblies (I maybe could have referenced less, but this works)

image

So we have a workaround, once setup it is used automatically. It is just a shame that the default web servers are all set to be x86 as opposed to Any CPU.

Problem setting an email alert for the TFS 2010 Power Tools backup

One of the very useful features of the TFS 2010 Power Tools is that it provides a backup wizard, great for teams using TFS who don’t have much SQL/IT Pro experience. Whist setting this up on a server I hit an interesting gotta with sending alerts.

This TFS server in question was configured to enable SMTP alerting (via the TFS Administration Console)

image

and this was working

During the backup configuration wizard you have the option to be send email if the backup job fails. The SMTP details are picked up from the TFS servers SMTP alert settings. When I enter a TO: email address and pressed the test button I got an error

image

Turns out the error was at the SMTP server end. The SMTP was set to only relay emails from known user (those with a local mailbox). To allow TFS to send alert emails the MYDOMAIN\TFSSERVICE account, used by TFS as a service account, had had a mailbox created.

I had assumed (wrongly) that the TFS backup system relayed it alerts via the TFS alert system. It does not, though it does pickup the alert systems setting in the wizard. This means that the email is sent using the account the backup service is set to run as, not the one used by TFS.

So as soon as set my backup process as MYDOMAIN\TFSSERVICE (earlier in the wizard) the email test worked and so did the whole backup altering process.

TF80070 when loading a team query in MS Project

I create a number of task work items in TFS 2010 using a list in Excel. This all appeared to work OK, and I could run a work item query in Team Explorer and see all my new work items. However then I tried to open the work item query in Project I got a TF80070 error. It loaded the work items up a point in the list then failed and showed error dialog.

I altered the query to remove the work item that it had failed on and it loaded without issue. After looking at the offending work item in more detail I saw the Title field had a carriage return in it. This did not bother Excel or Team Explorer, but Project obviously hated it. Once I edited the title (in Team Explorer) to remove the carriage return everything was fine in Project.

So if you see a TF80070 error, it might be a Project/Team Explorer patching issue as forums suggest, but also check for invalid characters in query fields

Windows search not starting, making itself disabled on a reboot

Since I got my new laptop I have had a problem that the Windows Search services in Windows 7 keeps setting itself to be Disabled whenever I restart the the PC. I usually notice this when I try to do a search in Outlook and I have to press enter in the search box to start a search, it is not matching emails as soon as I start to type.

If I load the services control panel I can enable the Windows Search service and start it manually, restart Outlook and everything is as I expect, but all a bit of a pain to do. I checked the Windows event logs, and it said nothing about Windows Search apart from my manual starting of the service.

Seems the issue was that I had set the service’s start-up action to be Automatic – Delayed. When I set it Automatic then it seems to start Ok. All I can assume is that something else in the start-up process is not completing soon enough so the delayed start search search never bother to even try, but I surprised there is nothing in the log, but it is working now!

Where has my mouse cursor done? Unable to record a video in Microsoft Test Manager

MTM has the feature that you can use Expression Media Encoder 4 to record the test run as a video. To enable this feature, after you install MTM, you have to install the basic version of Expression Encoder, and a few patches see notes here for a list of files and the process.

I recently did this on PC and tried to record a video. As soon as the recording process started the PC virtually stopped. It ran to 50%+ load on a dual core 2.3GHz CPU and the mouse disappeared. As soon as I stopped MTM (via task manager and the keyboard alone) it became responsive again. If I ran MTM without a video recording it was fine. Should be noted that if I ran the Expression Encoder (not via MTM) I got the same problem.

Turns out the problem was not the PC performance but the nVidia video drivers. Once I updated these to the current ones from the nVidia site it all worked as expected.

More on using the StyleCop TFS 2010 Build Activity– handling settings files

In a recent build I wanted a bit more control over rules used by StyleCop; in the past I have just tended to have the correct ruleset in the Program Files\StyleCop directory and be done with that. This time I wanted to make sure different rules were associated with different given solutions.

The StyleCop build activity does allow for this; there is a property to set the path to the settings file. In my build process template I set this property as below, via an assignment activity

StyleCopSettingsFile = String.Format("{0}\Settings.StyleCop", localProject.Substring(0, localProject.LastIndexOf("\")))

so picking up the settings.stylecop file in the solution folder, but you could use any logic you need here, or just pass the fixed path to the settings file as a build process argument.

So I placed an edited settings.stylecop in the same folder as my .SLN file under source control and ran a build. However when it ran more rules were evaluated than I had expected, in fact all the rules from the default ruleset had been used.

What I had forgotten to do was set the merge rules for StyleCop. So I opened the setting.stylecop file in the StyleCop editor (installed when you install StyleCop on the PC)

image

I then set the setting to not merge this ruleset with any other ones, and to always re-run all the results.

Once these changes were saved and the file checked back into TFS, StyleCop ran the rules I expected.

image