Tuesday, 7 March 2006

VMWare, TFS and Cloned Images

I'm having a real wierd problem trying to install TFS into a VMWare image and I wonder if anybody has seen the same thing and maybe has a solution. I have a VMWare image that is a Domain Controller and I create another image onto which I install TFS. If I create a clean VMWare image for the TFS the install works and I can create a new team project, however if I use a cloned image then the install succeeds but I cannot create a new team project.

What I tried is this. Create a 'base' Windows 2003 Enterprise image. Clone this and create a DC (this works). Clone the base image again and install TFS. That seems to work. However in the cloned TFS image I cannot create a new team project; each time I try I fail trying to connect to Sharepoint. The error I see is TF30177, I've hunted this down on various forums but none of the fixes works for me. If I do the exact same install on a clean (non-cloned) image then everything is fine.

For each cloned image I run the NewSid tool from SysInternals make sure the machine is in the domain and all the accounts are correct.

I've hit the same problems in Beta3 refresh and in the RC. Anybody with any ideas feel free to contact me.

Updated March 8th 19:00

I had two replies to this from colleagues. One from Dominick Baier who pointed me at this post thinking I had the same issue. I tried this, rebooting after each step, but no luck. The cloned image still failed.

Then I had an email from Mark Smith. Mark had had a similar issue and he pointed me here. Mark thought I had the same worker process problem that he had. But comparing the "linked clone" VM I had with the full clone the IIS setups looked exactly the same. However, something else in Mark's post caught ny eye: he said

"You must install IIS after installing Active Directory"

Now, the base VNWare image I was cloning had IIS installed. I would then clone and add the cloned image to the domain. Seeing the above comment I decided to first un-install IIS, then add the machine to the domain, re-install IIS and then do a full TFS install.

And it worked. I now have a linked clone with a full TFS install. Thanks to Dominick and Mark for suggesting things that pointed me in the right direction.

Posted by kevin at 1:10 PM in Net

Responses (0)

Sunday, 5 March 2006

Adding non-SQL Datasources to Web Test

A question I've been asked frequently is can I use something other than SQL Server as a datasource in, for example, a web test.

Sean Lumley's post answers this question.

Posted by kevin at 3:09 PM in Net

Responses (0)

Friday, 3 March 2006

VSTS Keyword Expansion

Just to answer a question from DevWeek, VSTS Source Control does not currently support keyword expansion

Posted by kevin at 8:01 AM in Net

Responses (0)

Thursday, 2 March 2006

VSTS References

For those folks that attended mine and Simon's VSTS talks at DevWeek and those who have been on the VSTS training classes I've put the VSTS references here

For those who have no idea what the reference list is, it's a collection of VSTS sites and references that I've found extremely useful when learning VSTS.

Posted by kevin at 3:21 PM in Net

Responses (0)

Unit Testing Web Applications in VSTS

I just realized I haven't blogged anything since the end of January. This is because I taught our first VSTS class in Boston at the end of January, and the buildup to that class was so intense that I decided to take it easy for a week or so, then other things start to pile up and less important things like blogging got left behind. Anyway, enough of my whining!

One of the chapters I taught in January was on unit testing web applications and web services. This is different to the web testing framework that comes as part of VSTS. In web testing you are performing functional testing of web applications. In VSTS you can also run in-web server tests on the code that makes up a web application. I will write another entry explaining how do to this later but here I wanted to point out an issue I found when unit testing web applications.

The lab we had written was ASP code had some security stuff going on, in particular it was using forms authentication and had an authorization entry that looked like this 

    <authorization>
      <deny users="?"/>
    </authorization>
and then another section to allow access to the CreateUser.aspx page that looked like 
  <location path="CreateUser.aspx">
    <system.web>
      <authorization>
        <allow users="*"/>
      </authorization>
    </system.web>
  </location>
This is a fairly normal setup for ASP, deny unathenticated access to the site but allow all users access to specific pages (in this case we want a user to be able to create an account for themselves).

This is pretty innocuous code until it comes to unit testing in VSTS. I have a 'proof of concept' unit test that simply does this: 

[TestMethod()]
[HostType("ASP.NET")]
[AspNetDevelopmentServerHost(@"C:\path to web site", "/StocksWebSite")]
[UrlToTest("http://localhost/StocksWebSite")]
public void WebServerTest()
{
    HttpContext context = HttpContext.Current;

    Assert.IsNotNull(context);
}
If you run this test using the web.config I showed above you will get the following error: The web site could not be configured correctly; getting ASP.NET process information failed. Requesting 'http://localhost:10672/StocksWebSite/VSEnterpriseHelper.axd' returned an error: The information returned is invalid.. Notice the reference to VSEnterpriseHelper.axd. So what is going on here?

It turns out that VSEnterpriseHelper.axd is the URL used by VSTS to trigger the runtime to load our tests into the web server (another entry on this in the future). Therefore that URL needs to be available to run. With the web.config we have all URLs (except CreateUser.aspx) are blocked to un-authenticated users, which means that VSEnterpriseHelper.axd cannot be accessed. There is one simple fix for this, allow un-authenticated access to the URL. You can add the following to your web.config and the testing code will work: 

<location path="VSEnterpriseHelper.axd">
  <system.web>
    <authorization>
      <allow users="*"/>
    </authorization>
  </system.web>
</location>

Hope that helps the next person who hits this problem,

Posted by kevin at 9:46 AM in Net

Responses (1)

« March »
SunMonTueWedThuFriSat
   1234
567891011
12131415161718
19202122232425
262728293031