Plain text return for WCF .svc Files From IIS

Well this was just painful.

We have just finished getting a .Net 3.0 dev environment set up to do some WCF development. Installed the NETFX30 runtime and the VS2005 Extensions, pointed a new IIS virtual directory at our WCF service host directory, and tried to access the .svc endpoint...

*splat*

IIS decides to return the svc as plaintext. Obviously something had gone pear-shaped as IIS hadn't had the .svc extension registered against ASP.Net. Nothing in the event log during the NETFX3 installation, and no obvious errors anywhere in the system. The only slightly odd symptom was HTTP response code 304 Not Modified in the IIS logs.

We tried repairing, reinstalling NETFX30, rebooting the machine, reinstalling IIS, clearing out the IIS metabase, manually trying to register .svc using the ServiceModelReg utility. We tried following the MSDN instructions to Deploy an IIS-Hosted WCF Service to the letter. Absolutely nothing worked.

At a moment of desperation we decided to download and install NETFX35, and then voila, it all worked. The closest we can find to explain this issue is a documented issue when upgrading from a beta to RC1 from the release notes (Section 2.7.4), however this machine had never had any betas installed on it at all, so didn't really apply.

The only other possible explanation we have is possibly some incompatibility with the two dozen other server products and frameworks that this machine had installed on it (including VS.Net, Eclipse, IntelliJ, Tomcat, Oracle, MySQL, SQL Express, WebLogic, custom ISAPI filters, and a plethora of different federated identity servers).

Just odd.

Anyway, we can finally carry on with our work now.

UPDATE:

This problem cropped up again this morning when I upgraded my NETFX30 dev machine (XP SP2, with IIS6) to NETFX35. After a bit of investigation and following the instructions at IIS Hosted Service Fails, I noticed that even though the .svc extension mapping had been properly configured for the top-level website, it had not been inherited by any of my virtual directories. This was quickly resolved by removing and re-adding the mapping on the top level website, thereby forcing all the virtual directories to get the new setting. A quick iisreset later, and we were back in business.

Still no closer to understanding why this is happening, although at least we know how to fix it now. Maybe its an IIS5 issue with NETFX3? And yes yes, before you tell me I should be developing server-side apps on Server2k3, I KNOW and its out of my control!

Java-WCF DateTime Interop

Here's the scenario:

We have a WCF IIS-hosted service with one of the parameters on the OperationContract being a standard DateTime parameter. The parameter logically represents a date with no time component e.g. DOB. When we write a WCF client that sends data to the service, the date argument is correctly serialized and sent across the wire to the service, no problems at all.

The problem emerges when writing a Java client. We generate the client proxy code by pointing IntelliJ at the WSDL, which then grinds out all the proxy code. OK so far. We start to write our client code to invoke the proxy and we notice, hey, our date parameter has been reflected out to be a 'Calendar' object. OK quick check of the javadocs tells us this shouldn't be a problem. So we write some code to get a date from the user:

SimpleDateFormat sdf = new SimpleDateFormat("dd/MM/yyyy");
sdf.parse("11/12/2000");
locator.getdefaultEp().invokeWsMethod(sdf.getCalendar());


Hmmm, a little bit more verbose than the equivalent C# code, but doesn't look like there's anything wrong with that. Lets send it off and see what happens...

Looking at the svclog file however tells us that the date parameter has been serialized to UTC:

<dateofbirth type="xsd:dateTime">2000-12-10T11:00:00.000Z</dateofbirth>


It appears that the default behaviour of the Java serialiser (JAXB in this case I believe) is that it converts the Calendar's value from the local machine's timezone into UTC, in this case (NZST) taking 13 hours off the passed in time. In order to get around this you must set the timezone to UTC before parsing the date string:

SimpleDateFormat sdf = new SimpleDateFormat("dd/MM/yyyy");
sdf.setTimeZone(TimeZone.getTimeZone("UTC"));
sdf.parse("11/12/2000");
locator.getdefaultEp().invokeWsMethod(sdf.getCalendar());


This will ensure the time is serialised and transmitted exactly as you want it. Not exactly rocket science once you understand the APIs however can be tricky to get there without know what's going on under the covers.

Some interesting background reading on Java and .Net date handling can be found at the MSDN article Coding Best Practices Using DateTime in the .NET Framework and the Sun Web Service Interop Tutorial

Ankh/TortoiseSVN and UltraCompare Settings

I always forget what the settings are to configure Ankh and TortoiseSVN to use UltraCompare as the default diff/merge tool, so for posterity here are the commands.

Diff:
C:\Program Files\IDM Computer Solutions\UltraCompare\UC.exe -t %base %mine

Merge:
C:\Program Files\IDM Computer Solutions\UltraCompare\UC.exe -rom %theirs %mine %merged

OH NOES!!!11 Nicks is on teh televizion

Fronde Anywhere took out the Innovation Award at Saturday night's Hi-Tech Awards

http://www.tv3.co.nz/VideoBrowseAll/BusinessVideo/tabid/369/articleID/38455/Default.aspx?articleID=38455

Look for the guy transacting online in a secure manner about halfway through the video

w00t!