# Tuesday, May 13, 2003
It's amazing how little things have changed on the web when you really look at the details. Lots of things that seemed like a good idea to a few people 5-6 years ago now seem like a good idea to a whole bunch of people. Scott Hanselman was musing about what ever happened to PointCast, which was quite the technology back in it's day. In response Don Box supplied a little piece of CDF, the PointCast equivalent used by IE 4.0. Sure looks a lot like RSS to me, without all the namespaces :)
Tuesday, May 13, 2003 2:05:59 PM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Monday, May 12, 2003

It seems like every time I come across something in the framework documentation that says something along the lines of "this works just fine unless" my application is firmly in the "unless" category :)

There is a new security setting in 1.1 that has to do with serializing objects over remoting which is much more restrictive than the 1.0 framework was. I recompiled my app against 1.1, fixed all the compile time bugs, tracked down all the dependencies, and then the real fun began: finding the runtime bugs.

It turns out that there is a new setting on the remoting formatters that won't deserialize your object by default unless they fall into a certain category of "safe" objects. Mine apparently don't, although going over the list on gotdotnet I don't see how my objects don't fall into the category of "low". Anyway, for whatever reason they don't, so I have to prompt the remoting formatters to use "Full" deserialization. (Low vs. Full???) Then everything works hunky-dory. I wish that the list of conditions was a little more exhausitve. The only things listed as for sure causing a need for "full" support are sending an ObjRef as a parameter, implementing ISponsor, or being an object inserted in the remoting pipeline by IContributeEnvoySink. I tried this with two completely different parts of my application, neither of which meet those criteria, and still had to use "full" support. Hmmmm.

Live and learn I guess.
Monday, May 12, 2003 8:01:17 PM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# 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]  |