Tomer Gabel's annoying spot on the 'net RSS 2.0
# Wednesday, August 17, 2005
I was implementing a watchdog system over a certain system's XML configuration repository using System.IO.FileSystemWatcher. Annoyingly, changes to the file (such as saving it with Notepad) would often result in the change event being fired twice. The system is designed so that whenever the file is changed, it is reloaded and several parts of the system are suspended (via thread synchronization) while the information is being re-cached. This in itself wouldn't be a problem since changes to the XML files are manual and rare, the XML schemas and serialization metadata are already cached etc. so the reloading operation shouldn't take more than 100-200ms (and the lock itself is only obtained at the very end of said process) - however there is a drain on CPU time and memory resources which I certainly wouldn't want doubled.

While it seems I wasn't the only one to encounter this behaviour, I've yet to see a proper solution to it; in the meanwhile I settled for a small hack where an update to the XML file are only processed if n seconds (2 in my case) have elapsed since the last update. Does anyone know of a cleaner way to solve this?

Wednesday, August 17, 2005 2:00:41 PM (Jerusalem Standard Time, UTC+02:00)  #    -
# Tuesday, August 16, 2005
I came across a fairly unusual situation today, where a referenced assembly contained XML schemas as embedded resources. The schemas may (and do) contain <xs:include> and <xs:import> directives, which could not be resolved when I was trying to compile the schema: the schemas were including other schemas by relative URI (for example, SystemConfig.xsd has an <xs:include schemaLocation="Base.xsd" /> directive), and when the schemas are loaded from a resource there are no URIs to speak of.

After a bit of reading I settled down to write a custom implementation of XmlResolver. It's used like so:

Assembly container = typeof( anyTypeFromTheResourceAssembly ).Assembly;
XmlResourceResolver resolver = new XmlResourceResolver( container );
schema = XmlSchema.Read( stream, new ValidationEventHandler( schemaValidationEventHandler ) );
schema.Compile( new ValidationEventHandler( schemaValidationEventHandler ), resolver );

Grab it here, and do let me know if you find this useful or have any comments/questions!

Update (18:58 GMT+2): Interesting. Apparently a developer called Jay Harlow wrote a similar class a while ago; his is VB.NET, mine is C#, but the similarity is staggering. So if you're looking for a VB.NET version of the class, there you are :-)

Tuesday, August 16, 2005 1:41:57 PM (Jerusalem Standard Time, UTC+02:00)  #    -
# Monday, August 15, 2005
I've been using NDoc a lot over the last couple of weeks and have found it invaluable. There is, however, one major hurdle I've encountered: it doesn't seem to support documenting of events. At all. Now I'm trying to generate documentation for one of our interfaces (which consists mostly of events) but can't :-(

I couldn't find anything relevant on the web (via Google or Google Groups). Ideas?

Monday, August 15, 2005 12:16:55 PM (Jerusalem Standard Time, UTC+02:00)  #    -

I've updated the lists of open source and proprietary software I use. I also consistently update the post about ReSharper 2.0 beta; finally, I've installed the new version of dasBlog.

The world is a better place, certainly.

Monday, August 15, 2005 10:48:27 AM (Jerusalem Standard Time, UTC+02:00)  #    -
# Sunday, August 14, 2005
Check this out: How to install Windows XP in 5 hours or less. I found this one particularly funny:
56. Time passes. It is getting dark. You are likely to be eaten by a grue.
I'll give a shekel (don't ask) to anyone who knows what that's all about :-) (well no, not really, but it's funny anyway).
Sunday, August 14, 2005 10:43:05 PM (Jerusalem Standard Time, UTC+02:00)  #    -
I was about to download log4net 1.2 beta 8, which I've been using for almost two years now, only to find that the project's been moved from SourceForge to Apache and an incubation release it out.

1.2.9 beta looks extremely impressive and I will report my comments on the subject as I become more experienced with it.

From the list of features the ones that impressed me the most are:

  • The new logging contexts; NDCs was always thoroughly useful (never found any use for MDCs though) and an extensible, scoped NDC should indeed prove useful.
  • PatternLayout customization; combined with the new logging contexts this seems to be an incredibly powerful tool (consider: conditional object state dumps with no little or no code overhead/clutter!)
  • .NET formatting syntax. Trivial but necessary.
  • Customizable levels for finer debug message granularity.
  • Per-appender security contexts: 'nuff said.
  • Pluggable file locking for FileAppender; I'm not readily sure where this would be useful, but I bet I'll find it before long...
I'm always impressed by open source goodness :-)
Sunday, August 14, 2005 3:17:51 PM (Jerusalem Standard Time, UTC+02:00)  #    -
# Saturday, August 13, 2005
Scott's released dasBlog 1.8! I don't have time to install it just yet - will probably save that for tomorrow. Since all the bugs I filed were fixed the new version is bound to be da bomb!

Update (August 15th, 11:32 GMT+2): dasBlog 1.8 is up and running. Oddly enough it seems to be compiled, or at least set up, to run in debug mode (web.config is set to <complication debug="true"... />), so I changed that. Everything seems to be in order.

The new BlogXP theme is very slick, but it's going to take quite a bit of time to rework it to fit the site design (get rid of the calendar, change the title, add a bit of personality...), so I'll stick with my modified DiscreetBlue in the meantime.

Saturday, August 13, 2005 8:22:37 PM (Jerusalem Standard Time, UTC+02:00)  #    -
Personal | Software
I went to see The Island in the cinema with a bunch of friends the other day. Hey, it didn't cost me anything so why not, right?

It's sort of 1984 (at least in the beginning) meets The Matrix (towards the middle). There are plenty of very high-profile actors who do a pretty good job with the mediocre script (including Ewan McGreggor, Scarlet Johansson, Sean Bean, Steve Buscemi and Michael Clarke Duncan) - there's even a guest role for our own Noa Tishby.

Bottom line: harmless generic action movie; ten years ago it might've been considered innovative but nowadays it's just a cash cow. The acting is, as I said, pretty good (considering the amount of star actors), the eye candy is great - but the movie itself is really uninspired.

Saturday, August 13, 2005 6:17:35 PM (Jerusalem Standard Time, UTC+02:00)  #    -
.NET Remoting is a pretty nice piece of technology. It theoretically allows you to tear out a class from the server code and use it remotely from a client; it features all sorts of nice features like SAO and CAO, lifetime leasing and sponsors, pluggable protocols and provider chains etc. But in order to effectively use it there are quite a few things the programmer should take into account: the obvious ones (serialization, object lifetime, state) and the less-obvious ones (object construction [for CAOs], security [e.g. typeLevelFilter]).

Today I'd like to discuss one these less-obvious issues, specifically the usage of events in remotable classes. For clarity, lets assume the following scenario: a Server has a singleton SAO factory for client registration. The CAO class is called IProvider. Suppose it has the following structure:

public delegate void ServerEventHandler( string message );

public interface IProvider
void ClientMessage( string message );
event ServerEventHandler OnServerMessage;

And suppose the client were to register itself to the event like so:

p.OnServerMessage += new ServerEventHandler( p_OnServerMessage );

What happens behind the scene is a little less trivial. Delegates themselves are value types which hold a reference to their target. So in other words, we are sending the server an object which holds a reference to our client class, in itself a MarshalByRefObject derivative. What happens when an object is marshalled by reference? Answer: a proxy is created on the remote machine. What happens, in effect, is that the server is trying to create a proxy of the client object, which requires the assembly containing the client object's type. A naïve implementation like the one above would result in the following error (click for a larger image):

The solution is something of a hack I originally found in this article; the general idea is that for every delegate defined in your shared interface you create a shim object. This object acts as an intermediary between the client and server, passing events from one side to the other; the shim itself is defined in the shared assembly, which means it is always recognized by both client and server. This way the server does not need to recognize the client object type:

The actual shim implementation is ugly but trivial. Here's one example of how to do this for the ServerEventHandler delegate:

public class ServerEventShim : MarshalByRefObject
ServerEventHandler target;

private ServerEventShim()

public void DoInvoke( string message )
target( message );

public static ServerEventHandler Wrap( ServerEventHandler handler )
ServerEventShim shim = new ServerEventShim(); = handler;
return new ServerEventHandler( shim.DoInvoke );

Now all that's left is to slightly modify the way the client registers itself for the event:

p.OnServerMessage += ServerEventShim.Wrap( new ServerEventHandler( p_OnServerMessage ) );

Be advised: the client is now effectively also a .NET Remoting server, which means you have to register a channel for it (you should use 0 for port; this instructs Remoting to use whatever available incoming port.) You are also serializing custom types here, which means you must also set typeLevelFilter=true for this incoming channel.

Finally, to be honest I'm a little astonished that the .NET Remoting team didn't realize this shortcoming and found a more reasonable way to do this (anonymous, automatically generated shim classes? Why not - there are anonymous, automatically generated proxy classes...) Oh well, another few hours down the drain.

Update (August 29th 09:45 GMT+2): As per the request of Peter Gallati, here's some source code demonstrating the technique. Feel free to drop me a line if you need any further help.

Saturday, August 13, 2005 2:14:54 PM (Jerusalem Standard Time, UTC+02:00)  #    -
I just installed The Gimp 2.2.8 on my laptop. Somehow when I used it on other machines I managaed to miss the fact that it's partially migrated to Hebrew, and that this mode is enabled by default on machines with their regional options set up accordingly.

Now, I can't stand Hebrew in applications so I generally always set localizable applications to English (including GAIM and even Windows itself); getting Hebrew menus is bad enough, but when they're only partially translated and the dialogs aren't RTL'd to begin with it looks absolutely terrible.

If you try to run The Gimp on a Hebrew-enabled machine I seriously suggest you set LANG=en in your environment settings.

Saturday, August 13, 2005 1:22:12 PM (Jerusalem Standard Time, UTC+02:00)  #    -
Send mail to the author(s) Be afraid.
<August 2005>
All Content © 2024, Tomer Gabel
Based on the Business theme for dasBlog created by Christoph De Baene (delarou)