But it works on my PC!

The random thoughts of Richard Fennell on technology and software development

Down in London for TechDays

I am down in London for the first two days of the Microsoft TechDays event. First day has been very interesting, there seems to be a good buzz over the new testing features. So it looks good for my session tomorrow when I will be presenting on Lab Manager hope to see you there.

Error running Ivonna tests with ASP.NET 4

When I tried to run a working Ivonna test, previously targeted at .NET 3.5, against .NET 4 I found my test failing with the error

------ Test started: Assembly: Webpart.Tests.dll ------
<html><body>Bad Request</body></html>
Setup information
Physical Web path: C:\Projects\Test\TypeMockSample\TestWebSite
Actual path: C:\Users\fez\AppData\Local\Temp\Temporary ASP.NET Files\root\156567f2

Turns out that the fix to simple, you have to use an absolute path i.e. the / in front of the BasicTest.aspx is vital

 

[TestMethod, Isolated]
        public void LoadWebPage_HelloWorldWebPart_NoError()
        {
            TestSession session = new TestSession(); //Start each test with this
            WebRequest request = new WebRequest("/BasicTest.aspx"); //Create a WebRequest object
            WebResponse response = session.ProcessRequest(request); //Process the request
            System.Web.UI.Page page = response.Page;
            //Check the page loaded
            Assert.IsNotNull(page);
        }

So this is a temporary work around for now, for me it is not an issue having to use a absolute path. I understand from the writer of Ivonna that this issue will be further investigated now that .NET 4.0 has RTM’d

Experiences upgrading to Lab Manager 2010 RC

Whilst preparing for my session at Techdays I have upgraded my 2010 Beta2 Lab Manager to RC. I am pleased to say the process is far more straight forward than the initial install. Again I used the Lab Manager team blog as my guide, they have revised ‘Getting started with Lab Management 2010 RC’ Parts 1, 2 ,3 and 4 posts to help.

I was able to skip through the initial OS/VMM setup as this has not altered. I chose to throw away my TestVM (with its Beta agents) and create a new one. I upgraded my TFS 2010 instance to RC. The only awkward bit was that I had to extract the RC version of the Lab Build Template from a newly created RC Team Project Collection and load it over my existing Beta2 version. I then recreated the Lab E2E build – and it just worked. My basic sample created for Beta2 build and tested OK.

I got confident then and so decided to build my own application with Coded UI tests, and surprise, surprise it work. OK this was after some reconfiguring of the Test VM to allow UI interactive testing, and a few dead ends, but basically the underlying system worked and I think I now have a working understanding of it.

The whole process is just much slicker than it was, and the online MSDN documentation is much more useful too. This is certainly becoming as more accessible product, but you still do need a good mixture of ITPro and Developer skills that I bet many teams are going to struggle to find in a single person. The best thing I can recommend is build your own system step by step (following the blog posts) so you know how all the moving parts interact. Once you do this you will find it is less daunting.

Running Fitnesse.NET tests using MSTest - Revisited

In 2008 I wrote a post Running Fitnesse.NET tests using MSTest.  Recently I had need to us this technique on a VS2010 project, and as is so often the issue the code that worked then does not seem to work now. All I can assume is that the Fitnesse API had altered, but I thought I was using the same assemblies!

So I pulled down the code from http://sourceforge.net/projects/fitnessedotnet/ and had a poke about. Basically I seemed to be using the command line switches wrong. The listing below shows what I found is the working usage:

[TestMethod]
    public void WorkFlowSwitchOnName_DataViaFitnesse_Success()
    {
        fit.Runner.FolderRunner runner = new fit.Runner.FolderRunner(new fit.Runner.ConsoleReporter());
        var errorCount = runner.Run(new string[] {
                "-i",@"WF Workflow", // the directory that holds the HTM test files
                "-a",@"TestProject.dll",  //we have the fit fascard in this assembly
                "-o",@"results"}); // the directory the results are dumped into as HTML
        // fit can fail silently giving no failures as no test are run, so check for exceptions
        Assert.AreEqual(false, Regex.IsMatch(runner.Results, "^0.+?0.+?0.+?0.+?$"), "No tests appear to have been run");
        // look for expected errors
        Assert.AreEqual(0, errorCount, runner.Results);
        
    }

The –i option is the one that was wrong. I had been specifying a single HTM file. What I should have done was specify a directory that contains one or more HTM files. I handled this as a sub directory in my project with its contents set to copy to the output directory.

Once I made these edits I had my tests running again as expect.

TF30046 Error when trying to create new team project collection using an existing empty DB

I my previous post I discussed how the DB label was not used for TPC Dbs in 2010. As I was working on a setup where a central SQL box was the DT for two virtualised TFS AT instances, I therefore needed to create my TPC databases manually if I wanted TPCs of the same name on each TFS instance.

I won’t go over the old post again, but in essence I was trying to create a TPC with the name ABC on a TFS instance with a database label of RC. So I tried to create the DB TFS_RC_ABC manually and pointed the TPC create process at this. It passed the verify but I then got a

TF30046: The instance information does not match

error during the core stage of the TPC creation. Basically the empty DB was found and used, but the wizard checking on the IDs of DB and the TPC found they don’t match.

It seems  the name of the DB is the problem for pre created DBs.  I tried altering the prefix from TFS_RC, changing to just RC_, removing the _,  and eventually all the prefix, but to no effect. However, when I altered the end of the DB name so it did not match the collection name it worked

So the workaround is if I create an empty DB called ABCRCTFS,  create a collection called ABC (using ABCRCTFS as the empty DB) all seems to be OK, including that all the URLs for the collections and SP sites include the name ABC, it is just the DB has an unexpected name.

I will post again if I get a better solution or and explanation in the future.

Mixed mode assembly is built against version 'v2.0.50727' error using .NET 4 Development Web Server

If your application has a dependency on an assembly built in .NET 2 you will see the error below if you try to run your application when it has been built in.NET 4.

Mixed mode assembly is built against version 'v2.0.50727' of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information.

This can be important in VS2010 testing, as test projects must be built as .NET 4, there is no option to build with an older runtime. I suffered this problem when trying to do some development where I hosted a webpart that make calls into SharePoint (that was faked out with Typemock Isolator) inside a ASP.NET 4.0 test harness

The answer to this problem is well documented, you need to add the useLegacyV2RuntimeActivationPolicy attribute to a .CONFIG file, but which one? It is not the web.config file you might suspect, but the C:\Program Files (x86)\Common Files\microsoft shared\DevServer\10.0\WebDev.WebServer40.exe.config file. The revised config file should read as follows (new bits in red)

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <startup useLegacyV2RuntimeActivationPolicy="true">
            <supportedRuntime version="v4.0" />   
  </startup>

  <runtime>
    <generatePublisherEvidence enabled="false" />
  </runtime>
</configuration>

Note: Don’t add the following <supportedRuntime version="v2.0.50727" />  this cause the web server to crash on start-up.

TFS 2010 Database Label not use for Team Project Collection DBs

Found out something I did not know today, the TFS 2010 database label is only used for the server’s own primary configuration databases not for the DBs for the TPC it creates.

For example on a 2010 RC install with the database label was set to RC during the installation. When I try to create a new TPC (called ABC) it tries to create a Db named TFS_ABC, even though the database label for TFS server can be seen to TFS_RC_  on the admin console and the instance’s primary databases are called TFS_RC_Configuration, TFS_RC_Warehouse and TFS_RC_Analysis.

image

I would have expect the new db to be call TFS_RC_ABC.

This can become interesting if like me you are working with a number of TFS instances that all share the same central SQL server instance. So if you want a TPC of the same name on two or more TFS servers that share a DT you must manually create the empty DBs to avoid a name clash.

So not a major issue but confusing if you don’t know it is a problem.

 

TF254024 error when upgrading TFS 2010 Beta2 to RC

Whilst upgrading a single server instance of TFS 2010 Beta2 to the RC I got a TF254024 error. This occurred at the point in the upgrade wizard where it tries to list the databases available to upgrade.

The reason for the error was the account I was logged in as (the domain administrator in my case) did not have rights on the SQL instance to see any TFS DBs. Once this was sorted, by granting owner rights to all the TFS DBs, all was OK.

I think it had got into this state as this was a ‘standard’ TFS install using an automatically installed SQLExpress instance; so rights had not been explicitly assigned during the TFS setup. By installing SQL 2008 Management Studio Express and logging in as the servers local administrator I was able to grant the rights needed.