But it works on my PC!

The random thoughts of Richard Fennell on technology and software development

Old assemblies appearing in the _PublishedWebsites directory with Team Build

I have been having a problem with a new automated CI build under Team Build that I have added to an old Visual Studio solution. The solution is fairly big, but in essence it contains a shared data type assembly, a web site front end and a back end web service. The problem was on the Team Build drop share in the _PublishedWebsitesproduced by team build I was finding a old version of the shared data type assembly. However in the release directory of the same build I found the correct newly built version of the assembly.

After much fiddling with build order and dependencies I found the problem. It was that the web service project was originally created as a VS2003 or 2005 website a good few years ago (so long ago I can't remember which); the point is it was not a web application, hence there had been a bin directory under the root in Visual Studio.

When this project was converted to a VS2008 web application this was tidied up in Visual Studio. However in the TFS source control the bin directory remained. This was not an issue when the project was build locally in Visual Studio as:

  1. Visual Studio did not pull the files down as the directory was not in the project
  2. They would have been overwritten anyway as part of the build

However on Team Build :

  1. The files did come down to the build server (due to the workspace scope)
  2. They were not over written due to Team Build having a separate source and binary paths.

So these files, in the unwanted bin folder, ended up being copied to the drop location after the newly built version of the shared assembly, as part of the copy of web site resource e.g. graphic files. The net effect being to leaving me with an old DLL in the _PublishedWebsites folder, whilst having the correct new version release directory.

This was only found in the end by detailed checking of the copy lines in the build log.

PostBuild events not running on TFS Team Build

I have been struggling today with a problem that a PostBuild event on a C# project works fine on my development PC but failed on a Team Build box. The project is based on the Codeplex  SharePoint Visual Studio Project Template that uses post build scripts to create a deployment WSP.

It turns out the problem was an unwanted condition on the PostBuildEvent in the projects .csproj file. It was like this:

    <PostBuildEvent Condition=" '$(TeamBuildConstants)'=='' ">
          echo POSTBUILD STARTED

when it should have been

          echo POSTBUILD STARTED

Where this condition came from I am not sure, as if I create a new project of this type from the sample template it was not there. As this was an existing project I guess it got edited in at some point in the past, why I can’t think. Anyway it is awkward to spot if you don’t look at the .csproj file in notepad.

We are hosting Microsoft's Azure Technical Briefing

Interested in finding out more about Microsoft's Cloud computing strategy and the technology behind Azure? Yes - well you are in luck there are more UK Microsoft road show events in February. They are in Cambridge, Edinburgh and the one we are hosting in Bradford on the 13th.

For more details and links to registration see http://blogs.msdn.com/ukisvdev/archive/2009/01/14/new-dates-for-azure-technical-briefing-announced.aspx

Writing a webpart to work inside and outside Sharepoint when talking to WCF

I have posted in the past on porting our ASP.NET bug tracking systems into Sharepoint and also linking it to TFS. The idea being that the initial customer support contact is tracked in the call tracking system e.g. is it switched on, is there paper in it....., and then escalated to TFS when development effort is required. To do this escalation my webpart calls a WCF service to access the TFS API - why you ask? The TFS API is 32bit only and you cannot call it directly inside a Sharepoint 64bit server farm.

It is good to be able to test this webpart/wcf setup outside of Sharepoint, it is faster and avoids any deployment issues. However, I did hit upon an issue when doing this. When running in Visual Studio it reports a problem that it cannot step into the WCF code; in fact this is a bit of a red herring you cannot even connect in any way.

The fix is simple, you need to set the WSHttoBinding settings, that you use to pass the AD authenticated user, differently in Sharepoint and outside it in Visual Studio running the webpart on Cassini. Basically the default is fine for Cassini (assuming the WCF service web.config is set for WIndows authentication), but you need to set some extra settings if hosted in Sharepoint.

For us I fixed it by using the DEBUG compilation flag, so when running locally it uses the Cassini settings (or lack of them) and when built for deployment (via a WSP) the extra SharePoint settings are used.

var binding = new WSHttpBinding();
#if !DEBUG
     // we were using the following lines but these cause debug to fail
     // but we need them get the AD context for connection to TFS if in Sharepoint
    // As we only deploy a release build this #if is OK
    binding.Security.Mode = SecurityMode.None;
    binding.Security.Transport.ClientCredentialType = HttpClientCredentialType.None;
    binding.Security.Message.EstablishSecurityContext = false;

var tfsClient = new BlackMarble.Sabs.WebParts.SabsTfsLinkReference.WorkItemLinkClient(binding, new EndpointAddress(tfsLinkURL));

Call for speakers for DDD South West

DDD community events are getting another venue this year, Queen's College in Taunton on the 23rd of May.

It has been decided that some of the speaker will be regulars from other DDD events; including myself speaking on Scrum. However all the other slots will be filled in the usual submission and voting manner, with the added rule the speaker should be new to the conference circuit (speaking to user groups is allowed and encouraged). So is this you? do you fancy speaking? if it is then submit a session.


Problem hosting WCF using Cassini on Windows 7

I have been working on an internal legacy application at our place that is being slowly moved from ASMX to WCF services. At present the services are a mixture of the two and there is a new WCF based client making connections to both types as needed. This work has been going on for a while on Vista development boxes without any problems. However when I opened the solution on a Windows 7 box (Beta 7000 build) I found I could not access the WCF services hosted locally using Visual Studio 2008’s WebDev.Webserver.exe (Cassini) server.

After a bit of digging I stripped the problem back to this:

  • In VS2008SP1 create a new ASP.NET hosted WcfService, Don’t altered any of the content from the demo/sample that is in there i.e. the GetData method etc.
  • Run this from within VS2008 so it is using WebDev.Webserver.exe on some port number chosen by Visual Studio, a browser will be opened and you will be able to see the WDSL
  • Connect to the service using the WCF test client (C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\WcfTestClient.exe).
  • It gets back the WDSL but when you try to execute a method you get the following error. The remote server returned an unexpected response: (400) Bad Request.

I tried disabling firewall, anti virus etc. but it all had no effect. I looked with Fiddler2 and there appears to be no communication to the service (remember to look at localhost in Fiddler you have to using (note the trailing dot) or see the FAQ for other techniques.

I then repeated the process, but create a self hosted WCF service (that uses C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\WcfSvcHost.exe) as opposed to an ASP.Net one, and this worked perfectly. Also if I published the ASP.Net WCF service to a IIS server it also worked fine. So this definitely looked like a Cassini issue.

I fed these result back to Microsoft and just heard that there is a problem with one of the security initiation messages when Cassini is involved, and they are looking into it.

So for now avoid the combination of Cassini, WCF and Windows 7 Beta, the simple workarounds on Windows 7 are

  1. to make your WCF services self hosted during development.
  2. or host in IIS on you development PC

In both cases you can chose how to host them in production, it does not have to be the same, that is the great advantage of WCF.

Installing an MSI on Windows 7 fails after 16th January 2009

I am using Windows 7 Beta on my main PC, whilst trying to install an application today I hit a problem, the installer failed on start-up. Firstly I thought it was a corrupt MSI so I tried another application, but it did the same. When I checked the Windows Application event log I found the following

Faulting application name: msiexec.exe, version: 5.0.7000.0, time stamp: 0x49432105
Faulting module name: ntdll.dll, version: 6.1.7000.0, time stamp: 0x49434898
Exception code: 0xc0000005
Fault offset: 0x00000000000ebbaa
Faulting process id: 0x7dc
Faulting application start time: 0x01c97a77da8e8b3e
Faulting application path: C:\Windows\System32\msiexec.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll

I next hit the forums and found that I was not alone with this problem, it seemed to start around the 16th of January, some people were putting it down to a corrupt Windows Defender update.

The solution was to use the Control Panel Restore tools to roll back to a restore point before the 16th. As this is a newly installed PC I have installed something most days, so it was easy to find such a restore point and roll back.

Once this was done the MSI, lets us see of the problem re-occurs

Update (day of post): I reran Windows Update and it wanted to install ‘Definition Update for Microsoft Forefront Client Security (Antimalware 1.49.2086.0)’, I let it do this and I can still install MSI, so it seems the rollback is a valid solution

Update 22nd Jan: Here are other reports of the same problem and some reported workaround http://www.neowin.net/news/main/09/01/19/windows-7-beta-testers-find-critical-windows-installer-bug