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:

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

when it should have been

<PropertyGroup>
    <PostBuildEvent>
          echo POSTBUILD STARTED
    </PostBuildEvent>
</PropertyGroup>

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

Interesting 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;
#endif

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

.csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, "Courier New", courier, monospace; background-color: #ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; }

New name for the XP Club and next months event

The details of the February meeting of the Agile Yorkshire User Group (new name, and new web site is on the way, watch out for posts)

The session is on developers experiences of TDD, another view from the coal face. See you there, 2nd Wednesday of the month as usual....

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.

Voting opens for SQLBits IV

You can vote for sessions at SQLBit IV as of today at http://www.sqlbits.com/information/PublicSessions.aspx, you do need to join the site first. Note joining the site is not the same as registering to attend the event which has not opened yet.

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 127.0.0.1. (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

Another call for speakers

Just seen that there has been a calls for speakers for DDD Belfast, another chance to meet up with like minded developers.

XP Club January 2009 Meeting

The XP Club did not manage to book the usual venue, the Victoria Hotel Pub in Leeds, for this months meeting as it was already booked. So for one month only, on the 14th of January, will be next door to Victoria Hotel Pub at the O'Neils from 7pm.

Also, it has been decided there will be no technical presentation this month, we will meet to discuss the issues and politics around the club, including club's constitution, bank accounts, rough strategy for the future and so on. You are all welcome to come along and help to shape the future of the club, help with some duties or just come to meet-up with fellow geeks.

As of February we will be back at the Victoria Hotel Pub.

First thoughts on Windows 7 Beta

I had the PDC CTP on my Netbook and that was OK so I had not expected any major issues. That said it has not been without problems, but all the issues I have logged as part of the beta program have been related to hardware detection (missing base stations and ignored physical Wifi switch state) on my Acer laptop. However, these issue can be worked around i.e. don’t use sleep or hibernate. so have not stopped be using the beta on my primary PC.

As to using Windows 7, I like it. I am find the revised UI easy to use, and it certainly seems faster than my Vista build on the same PC, but this might just be the fact it is fresh install on a formatted disk.

I will report more then I have used it for a few days in the real world

Session submission for SQLBits IV has been opened

It is good to see how fast sessions have been submitted for SQLBits, a nice range already. And great news that the event on the 28th March is in Manchester.

I have submitted an updated version of the session I did for SQLBits II on Team System, hope some people find it interesting.