# Wednesday, May 07, 2003
Here's an interesting scenario:
I started out with an XSD schema, lets call it myObject.xsd. Using xsd.exe, I generated a set of classes to represent the objects in the schema. Straighforward so far...

This part works fine, and I can read and write the objects using the XmlSerializer just as I would expect. The issues started when I tried to get SOAP and WSDL involved. I wanted to return one of the objects definied in myObject.xsd (and correspondingly in myObject.cs) from a Web Service method.

   [WebMethod()]    public myObject ReturnMyObject(){}

The WebService class has an attribute specifying its namespace

   [WebService(Namespace="http://me.com/MyNamespace")]    public class MyWebService : WebService{}

When I try to create a proxy class for the web service using either wsdl.exe, or VS.NET 2003, I get an error claiming that the type myObject is not defined, the schema can't be validated, and no classes will be generated.

It turns out that the crux of the matter was that when I wrote myObject.xsd, I didn't explicitly define a targetNamespace, so when xsd.exe generated the classes, it added an XmlRootAttribute(Namespace="") This conflicts with the namespace specified for the service, so when the WSDL gets generated by the framework, it's no wonder the schemas don't all line up.

Once I went back and fixed the targetNamespace in the schema, everything worked just fine. It makes sense why this would be an issue, but it certainly took a while to track down.

Wednesday, May 07, 2003 7:00:28 PM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
A fabulous piece on async calls in .NET from Chris Brumme. The stuff that guy has in his head is truly amazing.
Wednesday, May 07, 2003 1:52:17 PM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Thursday, May 01, 2003
There's a new spec out from the Open GIS consortium for defining an XML representation of sensor data. It's pretty verbose, but most of it is optional. I would love to see something like this take off as a standard way to get data from sensors. There are a couple of existing standards for sensor data (ModBus, UCA, DNP, etc) but they are all binary. A fairly complete XML based standard would make our (or at least my) lives much easier.

Now we'll just have to wait and see if it takes them as long to finish as XLink is taking :).

It's nice to see that they used the XML Schema diagramming in XML Spy for their schemas. It's the best one I've seen, and makes it much easier to follow.

Thursday, May 01, 2003 6:38:56 PM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
I'm working on designing a SOAP API for getting data from some monitors out in the field back to a central server farm for aggregation, and the more I get into the details the more interesting it gets...
One of the biggest restrictions is that the monitors may well get deployed behind someone's firewall. All of the typical SOAP examples are between what are essentially peers on the internet, e.g. two web servers exchanging business data. In this case, since most people aren't going to punch a hole in their firewall for the monitor, we have to assume that all traffic has to originate from the monitor.
This ends up having a big impact on the semantics of the API, since if the central server wants to do something like send new configuration information to the device, it can't send it directly, which means waiting until the monitor "phones home" and asks for updates. This in turn means that the server has to cache any data going down to the monitor until the monitor checks in, and so on.
Anyway, the design is still ongoing, but having to model a SOAP API that always has to orginate from one side, and yet represents two way converstation presents some unique challenges.
There are even more issue when one side of the equation happens to be running on an embedded platform with 16Mb of RAM. :) but more on that some other time.
Thursday, May 01, 2003 5:06:30 PM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Monday, April 28, 2003
You would think that compiling resources for .NET using resgen would be pretty straightforward, and most of the time you'd be right.
However, if you are trying to automate your build process by running resgen through some autmatic batch process (I happened to be using Draco) there's one little problem. If your resource file (.resx) happens to contain any embedded bitmaps or icons, the resgen compiler wants to turn them into real bitmaps during the compilation process.
Apparently, in order to do this, it really draws the bitmaps, and in doing so requires that there be a current desktop context into which to draw said bitmaps. If you run as a service (or in fact build using a batch file launched as a scheduled task) there isn't any desktop context. Resgen happily returns an exit code of 0, and fails to actually compile any resources. This took me a while to figure out as it was, but what to do about it is an even thornier problem. It turns out that when you call the underlying Win32 CreateProcess function, you can tweak the STARTUPINFO struct to set the desktop to something meaningful. Unfortunately, there's no way to get at that struct from managed code.
After contemplating changing the code in Draco in some nasty way, I finally discovered that if I ran my Draco.NET service as "Local System" and checked the box that says "Allow service to interact with the desktop" that the resource compilation would succeed. However, other bits of my build process failed because while running as local system I could no longer use SSPI authentication to my CVS repository, or copy files to network shares when the build finished.
Many triles and tribulations later (and some very strange network permissions here and there) it's now working again, but it took a good 7-8 person days to resolve the issue.
Monday, April 28, 2003 4:37:20 PM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Thursday, April 03, 2003
I'll be speaking this weekend at the Portland Access User's Group Database Designer's conference. Should be fun. It's at the lovely Silver Falls Conference Center. With all the rain we've been having the falls should be pretty spectacular. I'll be talking about Web Services, SQLXML and MSDE as they relate to Access.
Thursday, April 03, 2003 2:54:23 PM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
# Wednesday, April 02, 2003
One of the more interesting features of .NET has got to be the ability to do shadow copying. Shadow copying means running an executable, but before you run it you copy all of it's files to some other location and run them from there. It's the mechanism that ASP.NET uses to deal with changes to .aspx files. When your ASP.NET files run, they're really running from somewhere else, so you can change the aspx files and they can be recompiled. It also means that you can do autoupdates of your own apps.
Wednesday, April 02, 2003 9:57:37 PM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
# Wednesday, March 12, 2003
Even if your are prepared for a disaster, are you prepared to help?
I just finished training for our local CERT (Community Emergency Response Team) here in lovely Hillsboro, OR. It was quite an interesting experience. We received (free) 24 hours of training from the fire department on how not only to protect ourselves and our families in time of disaster, but how to help our neighbors and communities as well.
Training included fire supression, search and rescue, and disaster medical operations among other things. Well worth knowing. And to finish up the class we had a simulated emergency, with live victims and everything :)
Now that I'm done with the basic training, it's made me want to go out and get a ham radio license and / or an EMT license. Pretty exciting stuff.
Lots of other communities have similar programs, so if you are interested and saftey and community service, check with your local fire department or city/county emergency manager.
Wednesday, March 12, 2003 5:35:04 PM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
I continue to be amazed at how easy it is to build a fairly complex and robust development environment around VisualStudio.NET using open source tools. We are using NAnt to do our builds, Draco.NET for continous integration builds, and NUnit for unit testing. I've just started experimenting with using a Wiki for internal product documentation, and so far it's working out very well. It's so easy to organically grow your documentation, with much less overhead than traditional document or content management tools. Playing with Wiki is what finally led me here, to my own weblog. I know it's all the rage, and I've been avoiding it, but here I've finally caved, largely because I was impressed with the content on a friend's blog. If you are interested in .NET development, check out Scott Hanselman's blog at www.computerzen.com
Wednesday, March 12, 2003 2:27:28 PM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [1]  | 
# Tuesday, March 11, 2003
This is my first post in the Patrick Cauldwell's Weblog blog.
Tuesday, March 11, 2003 9:31:15 PM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  |