Nuggets

shock an update!

Duncan Millard — Tue, 10 Jan 2006 12:18:00 GMT

Well, Owen has been bugging me to blog... so just to keep him quiet, here's something random...

If you want to hook up on the XBox 360 then here's my Gamercard!

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?

Just click this link!

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.

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 :-)

Lack of Updates

Duncan Millard — Wed, 18 Aug 2004 08:42:00 GMT

Sorry it's been quiet recently, but I've been travelling a fair bit, working on customer sites, and wading in to some good old BizTalk 2002 stuff. I'm also 3 weeks away from delivering my M.Sc. Thesis that I've been working on part time since January with The Open University, so my spare time is being sucked into that. Also the really cool side projects I've been doing with BTS2004 I can't really blog about at the moment :-(

Look soon for a little update to Scott Colestock's NAnt script (anybody know where he's got to?...) and some details about Web Services and BizTalk.

Sourcesafe, Schemas and Encodings

Duncan Millard — Thu, 08 Jul 2004 12:54:00 GMT

Just a quickie that might save you a lot of pain if you are working with schemas and files in UTF8, or that started in UTF8 but you've subsequently changed to unicode...

If you are getting lots of complaints about the encoding changing when you check in, or finding your files suddenly having Foo at the end of each line, make sure Sourcesafe has your files checked in as Binary rather than Text files.

To do this, open up the SourceSafe client, right click the newly added schema, and make sure Sourcesafe has flagged it as Binary instead of Text.

You can also use the Binary_Masks setting in the SRCSAFE.INI or SS.INI files:

Binary_Masks = *.XSD

If you don't do this, you might/will find Sourcesafe corrupting your files. It seems to be worse if you regularly flick between VS.NET Schema editor, BTS schema editor, and XML Spy's schema editor.

For more, see here.

Solving the BizTalk 2004, Web Services, and the "Underlying Connection was Closed" Problem

Duncan Millard — Fri, 25 Jun 2004 11:40:00 GMT

If you are consuming a remote web service from BizTalk (or ASP.NET) and you are behind a proxy server, you may receive an exception when BizTalk tries to call that web service:

System.Net.WebException - The underlying connection was closed: Unable to connect to the remote server
   at System.Net.HttpWebRequest.CheckFinalStatus()
   at System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult)
   at System.Net.HttpWebRequest.GetRequestStream()
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)

You can fix this by altering your machine.config file to explicitly hold the proxy details, as described in KB 307220.

The problem occurs because by default machine.config instructs .NET to use the Internet Exporer proxy settings. The account under which BizTalk (and ASP.NET) is running will not have a loaded user profile, hence there are no Internet Explorer settings available to it.

Hopefully this fix, plus Jan Tielen's blog (repeated at the bottom of KB 819450), will solve most of your web service consuming problems.

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

Web-Based SQL Server Enterprise Manager

Duncan Millard — Wed, 19 May 2004 07:28:00 GMT

The ASP.NET Enterprise Manager is a pretty funky web-based, Open Source version of Enterprise Manager. Think of it as a very good cover version of the original ;-)

Two immediate benefits are obvious:

MSDE users have a proper management tool at last
No need to install SQL tools locally or use a Remote Desktop Connection just to administrate SQL Server

There's still a reasonable TO-DO list for the tool, but it's pretty usable as-is.

Sourcesafe, Virtual Machines, and BizTalk Server 2004

Duncan Millard — Fri, 14 May 2004 06:57:00 GMT

This probably belongs in the "really, really obvious" category - but since it is also really really useful, I'll blog it :-)

Installing BizTalk 2004 isn't just a "Double click setup.exe" job, so it's nice to create a Virtual Machine containing your one-stop dev environment, containing SQL, VS.NET, BTS, NUnit, and so on. It's also nice to be able to connect up to network resources such as Sourcesafe, the Internet, and so on.

Now, networks don't like multiple machines with the same name, so if two developers indiscriminately start up the VM with normal networking enabled, it causes problems. Renaming a BTS server is a whole world of pain, but luckily there's a far easier solution - simply configure Virtual PC to use "Shared Networking (NAT)". This sets up a virtual NAT with your host machine as the gateway, meaning the network can't see your VM but your VM can see the network

To access your main network resources, you then have two options:

1) Using the "Local Users and Groups" MMC snapin, create an account on your guest OS with the same account name and password as your main domain account. As long as you keep the passwords in sync, you will be able to use domain-authenticated resources (such as Sourcesafe) without any further authentication just by logging in to your VM as that user. (For a discussion of why, see Keith Brown's excellent "Programming Windows Security" book).

2) If you don't want to set up a local account, you can authenticate yourself to any server by doing the following:

- From a command prompt, type net use \\<servername>\ipc$ /user:<your domain name>\<your user name>

- Enter your password when prompted

- You are now domain-authenticated on that server.

If you use this method to connect to your SourceSafe sever then when you run sourcesafe you will be asked for your username. Just enter your network login name (eg 'dotnetdunk') and you can use SourceSafe as normal.

Personally, I prefer option 1 ;-)