Architect or Cobbler?
Good code starts with good design

The end of an era

Wednesday, March 05, 2008
Or that's what it feels like. After 8 years I've decided it's time for me to move on, so I've left QA-IQ and branched out into the big bad world of freelancing. So my blog is moving as well, you'll now find it at http://www.jghd.co.uk/blogs/JamesWinters.

For my loyal band of 2 readers, that means you'll have to update your bookmarks. It will also hopefully mean that I'll start blogging more (but previous evidence doesn't actively support me here)

# posted by James @ 7:43 PM   0 comments

Hubris ...

Saturday, November 24, 2007
is a funny word, look it up here if you don't know it :-)

This afternoon's presentation on Facebook brought me to earth with a bang. My Internet connection crashed, then I attached to the wrong process , and finally I forgot how to code. The audience were kind, they clapped, but they should have booed.

And to top it all off, this is the presentation that got video'd.

Still, the slides are here, and the source is here.

# posted by James @ 8:59 PM   1 comments

DDD6 - One down, one to go

Well that's the first talk on the Entity Framework done. Had a full room, people sitting on the floor, and overflowing into the halls, so that was good. The demos all worked, so that was even better. And the practice at last week's user group was extremely useful, because I didn't even overrun.

The slides are here, and the source code with appropriate comments is here.

If you have any questions, just ask them in the comments section.

# posted by James @ 1:35 PM   2 comments

Contrary to popular belief ...

Sunday, November 11, 2007
I'm still here, and most of the time I'm even managing to architect, and not cobble.

It's been an exciting time recently, learning and applying new technologies (primarily .Net 3.5, but also the new Service Component Architecture and Service Data Objects stuff from the Java community) and creating new architecture courses for one of my major clients.

On Tuesday I'm doing a talk on the Entity Framework for the .Net Developer Network user group in Bristol. More details here, but Guy Smith-Ferrier will also be talking about Astoria. So if you fancy an evening on data access technologies, then get yourself down.

# posted by James @ 7:47 PM   2 comments

DataContracts and VB - A warning

Thursday, January 04, 2007

We always write our .Net courses as dual language courses, which is kind of hard for me, because I'm not the world's best VB programmer.  So I always do all the exercises as C#, and then convert them to VB at some point.  Yesterday i wasted a whole day because of the way WCF generates proxies for DataContracts.  Let me explain :-)

Just like web services, you can specify namespaces on your code which will be reflected in the WSDL, there is one important differecne however, there are 3 types of contract on which you can specify namespaces:

  • The Service Contract
  • The Message Contract
  • The Data Contract

If you leave the namespaces off then the service contract and the message contract get allocated the standard tempuri.org namespace we all know and love.  If you don't specify the data contract namespace then the framework allocates the namespace http://schemas.datacontract.org/2004/07  + the CLR type.

This is where it starts to go pear shaped, it works fine for C#, but in VB all namespaces belong to the rootnamespace, so instead of your types being serialized accross the wire with a namespace of something like http://schemas.datacontract.org/2004/07/LotteryService/

 they instead are transported accross the wire as

http://schemas.datacontract.org/2004/07/ConsoleApplication2.LotteryService

whereupon they are not deserialized correctly at the other end, and you therefore appear to always get null values sent over the wire.

This is infuriating to say the least, and there doesn't appear to be a great deal you can do to fix it.  Svcutil has a namespace switch which appears to be there to address the issue, so you can map a namespace to a CLR namespace, but it doesn't appear to do very much other than rename the generated proxy namespace.  What it should actually be doing is annotating the DataContractAttribute on the proxy type with the correct namespace, which is what I have to do to fix the problem.

So basically I dive into the the proxy and change all of my DataContracts from 

    <System.CodeDom.Compiler.GeneratedCodeAttribute( _
"System.Runtime.Serialization", "3.0.0.0"), _
System.Runtime.Serialization.DataContractAttribute()> _
Partial Public Class Entry
Inherits Object
Implements System.Runtime.Serialization.IExtensibleDataObject

to

    <System.CodeDom.Compiler.GeneratedCodeAttribute( _
"System.Runtime.Serialization", "3.0.0.0"), _
System.Runtime.Serialization.DataContractAttribute( _
Namespace:="http://schemas.datacontract.org/2004/07/LotteryService")> _
Partial Public Class Entry

The only problem with that approach is that I lose the annotation whenever the proxy is regenerated.


Of course I could always use namespaces like I'm supposed to :-)


# posted by James @ 7:58 AM   1 comments
This page is powered by Blogger. Isn't yours?