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:
- Visual Studio did not pull the files down as the directory was not in the project
- They would have been overwritten anyway as part of the build
However on Team Build :
- The files did come down to the build server (due to the workspace scope)
- 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.
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.
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
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();
// 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));
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....
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.
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.
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
- to make your WCF services self hosted during development.
- 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.
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
Just seen that there has been a calls for speakers for DDD Belfast, another chance to meet up with like minded developers.