C#/.NET Development

Handy XPath Expression Testbed

Duncan Millard — Wed, 05 Jan 2005 14:17:00 GMT

Ever wanted to quickly and easily try out different XPath expressions on your documents?

Some Overdue Plugging

Duncan Millard — Mon, 13 Dec 2004 14:54:00 GMT

A couple of blog entries that I wanted to highlight, but I've been a bit late blogging on (blame short-sharp-"just do this project before Christmas would you?" type work).

First, I'm sure you've all seen it by now, but Scott Colestock is continuing his barnstorming work on BizTalk deployment with NAnt. Check it out. BAT files are so 1980's ;-) If you're not doing something similar in your deployments (either through your own work, or using Scott's) then you are really missing a trick.

Also, a big plug must go to Thinktecture's new release of WSCF (WsContractFirst). As soon as I get two minutes to breathe (i.e. after Xmas), I'll take a proper look at this, but for now it looks pretty good.

WSDL First and BizTalk

Duncan Millard — Tue, 09 Nov 2004 17:38:00 GMT

I've held off posting on the WSDL-first approach so far because I've been waiting for the tools to arrive to make my gripes go away. Well, I'm still waiting... and waiting...

In the BizTalk world, we already have a Service Oriented mindset. We communicate in terms of schema-defined documents; we offer up services not APIs. We want to be interoperable with as many people as possible. I don't care whether you're using Java, .NET or ARM assembler - if you can send me a soap message, I'll talk to you. The trouble is that the .NET world approaches web services from a very object-y view point. Just pop a [WebMethod] in your asmx page and let ASP.NET create you some WSDL describing your objects. Easy, right, for people who want to knock up a quick web service in code?

The trouble is this promotes a very code-first approach. This really sucks from a BizTalk developer's point of view. I already have my schemas. I know the shape of the messages I want to receive. Where's the support for the Schema- and WSDL-first approach? The "publish orchestration" wizard seems ropey - a colleague today ended up with unusable WSDL just because he'd used an xs:import in his schema. Besides, I don't want a "publish orchestration" wizard, I want a WSDL designer with "create BizTalk orchestration template" and "import BizTalk definitions" options.

How about BizTalk's support for consuming web services? If I add a reference to a Web Service, I want the types defined in that WSDL added as first-class schemas in my BizTalk solution, not hidden under MyWebReference\Reference1.xsd. I want support for promoting properties out of the web reference - just remembering them if I refresh the web reference would be nice. Even worse, if I already have those schemas included in my solution please don't create a duplicate copy of the schema - share the reference (.NET 2.0 has an enhancement to WSDL.exe that may support this, I believe).

For the record, I am very much in favour of WSDL first. I just think there's an awful lot of pain to get it working in anything but the most simple cases. Let's hope Microsoft's new Domain Specific Languages designers lead to some WSDL designers pronto. XML Spy looks nice, but it's damned expensive!

This hasn't been a very structured post, for which I apologise, but I'd love to hear from anyone else who has found any silver bullets for BizTalk and WSDL-first...

XML Namespaces, Prefixes, and elementFormDefault

Duncan Millard — Wed, 20 Oct 2004 17:08:00 GMT

Note: The GeeksWithBlogs editor seems to keep really messing with the formatting / XML of this post. If you spot any errors, please hit the Contact Me link above and I'll try to wrestle it into submission again :-)

This entry may be useful to people confused by BizTalk's inclination to "ns0" at the drop of a hat :-)

Someone asked me today why their XML document wasn't validating. They thought that it was because the schema was expecting messages with a default namespace of "uri:my-namespace" but the document they were validating instead defined all the nodes using a prefix of "ns0", with ns0 mapping to uri:my-namespace.

One of the biggest misunderstandings in XML is namespaces. There's absolutely no difference to an xml parser or to the interpretation of a document whether you use a prefix on every node, or a default namespace. Prefixes are only a syntactic abbreviation. In other words:

<mydoc xmlns="uri:my-namespace">
<subnode />
</mydoc>
(Default namespace flows into the child - there is no prefix, so it uses the default namespace)

is identical to:

<ns0:mydoc xmlns:ns0="uri:my-namespace">
<ns0:subnode xmlns:ns1="uri:my-namespace" />
</ns0:mydoc>
(The prefix ns0 maps to uri:my-namespace, and both nodes are marked with ns0)

and to:

<ns0:mydoc xmlns:ns0="uri:my-namespace">
<ns1:subnode xmlns:ns1="uri:my-namespace" />
</ns0:mydoc>
(No default namespace, but ns0 and ns1 both map to uri:my-namespace and hence have identical meaning)

and

<ns0:mydoc xmlns:ns0="uri:my-namespace">
<subnode xmlns="uri:my-namespace" />
</ns0:mydoc>

(ns0 is defined on the parent, but we then set a default namespace for this node - and any children, if it had any)

In all of the cases above, the namespace of subNode is uri:my-namespace.

It turned out in the end that the problem was that the schema defined the namespace as "uri:my-namespace" but the result document was coming back with a namespace of "uri:my-namespace/" - the trailing slash being all important. Remember folks, namespaces are just strings - a trailing slash may not make a difference to most Internet browsers, but they do in XML Schema.

ElementFormDefault

As a bonus, a little note on elementFormDefault.

If in your schema you use elementFormDefault="qualified" then you can validate all of the documents above with a schema similar to (pseudo-code):

<xs:schema targetNamespace="uri:my-namespace" elementFormDefault="qualified">
   <xs:element name="myDoc">
      <xs:complexType>
         <xs:sequence>
            <xs:element name="subnode" maxOccurs="1" />
         </xs:sequence>
      </xs:complexType>
   </xs:element>
</xs:schema>

If you changed the elementFormDefault to "unqualified" then instead it would only look for the root element to be in the namespace, and child elements would be unqualified (in the empty namespace):

<ns0:mydoc xmlns:ns0="uri:my-namespace">
<subnode/>
</ns0:mydoc>

and

<ns0:mydoc xmlns:ns0="uri:my-namespace">
<ns1:subnode xmlns:ns1=""/>
</ns0:mydoc>
(An explicitly empty prefixed namespace definition)

and

<ns0:mydoc xmlns:ns0="uri:my-namespace">
<subnode xmlns=""/>
</ns0:mydoc>
(An explicitly empty default namespace definition for the sub node, and its child nodes if it had any)

I was lucky enough to learn about Namespaces on a Developmentor training course run by Aaron Skonnard ages ago so thanks to him for the foundations of this entry :-)

DateTime.Now and BizTalk

Duncan Millard — Mon, 04 Oct 2004 12:44:00 GMT

My colleague The Arch Hacker (dude, lame online name ;-), reports a supposed problem with DateTime.Now behaviour under BizTalk in that it seems to ignore daylight saving time here in the UK.

A little bit of lateral thinking and I've suggested that what it's probably doing is returning a timezone-free time. This is because BizTalk is running under a service account that does not have a user profile, hence there is no timezone information available to .NET. It is probably just using the BIOS time and treating it as universal time. In the UK, this just happens to be 1hr different to GMT, which makes it look as if it's the daylight savings time that's broken. That's just a red herring - it's actually just applying no timezone information at all.

I've not tested out this theory, but hopefully The Arch Hacker will do. .NET DateTime has a lot of hidden subtleties (mainly because it does not hold timezone information) and I strongly recommend every .NET programmer reads this MSDN article.

Visual Studio .NET XML Parser

Duncan Millard — Wed, 19 May 2004 11:55:00 GMT

Today I spent some time experimenting with the xsi:type to allow subclassing in my XML Schemas, as described in "W3C XML Schema Design Patterns: Dealing With Change" by Dare Obasanjo.

Many of the xsi:type examples on the web give the xsi namespace declaration as xmlns:xsi=http://www.w3c.org/2001/XMLSchema-instance.

.NET users look out! If you use this declaration in your XML instance document then it won't validate in VS.NET... you must reference w3.org, not w3c.org.

The correct declaration for the .NET parser is xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

Now, to replace that pulled-out hair...

UI Process Block: Let me help you

Duncan Millard — Tue, 04 May 2004 12:41:00 GMT

I've noticed a number of referrals from Google from people looking for help with the UI Process block.

Having spent some time with the UI Process Block I'd like to share my experiences, but to do that I would like to know what information people are after. Please leave me a comment below, or contact me directly using the "Contact" link above and I'll try to come up with some suitable articles.

Finally the obligatory plug: If you are looking for help with UI Process Block implementation, especially on projects that also involve BizTalk, my employer (www.solidsoft.com) specialises in BizTalk and .NET implementations so feel free to make an approach to learn more about us and (I hope) engage us commercially.

IMPORTANT UPDATE: I haven't worked with the UI Process Block for almost a year, so it's increasingly hard to devote time to looking into these issues. Please feel free to continue using my comments section to ask questions - but it's unlikely that I'll be able to chip in with answers. Don't forget the Got Dot Net workspace.

IMPORTANT UPDATE #2: I've now closed comments on this entry; please direct your questions to the official Got Dot Net workspace.

IMPORTANT UPDATE #3 :): Closing comments meant they weren't displayed any more; that was unintentional and seems to be a limitation of the .Text blog engine. Comments are open again so that you can see the old content :).

Managed calls to PInvoke

Duncan Millard — Wed, 28 Apr 2004 10:16:00 GMT

pinvoke.net is "a repository where you can find, edit, and add PInvoke signatures" ready for use in .NET languages.

Lovely! Thanks to this post on Eric Gunnerson's C# Compendium for the link.