When Java was first created, one of it's main strengths was "Write Once, Run Anywhere", or WORA for short. It didn't take long before developers realized this was an overstatement and WOTA (Write Once, Test Anywhere) was a more accurate description of this feature. This was true back then for AWT applications and still is today for J2EE apps.
Unfortunately, I have realized that .NET isn't much better in this regard. And I'm not talking about MONO here, I'm talking about the ability to run a .NET application on any Windows platform; something which I assumed would naturally hold true. Well we all know what they say about assuming things, and I guess I did make an ass out of myself when it turned out SharpReader was unable to run on Windows 98 & ME.
I finally figured out last night what caused this problem, and it turned out to be a library that has it's roots in the Java world: log4net. Not that this makes it Java's fault of course - log4j will happily run on any Windows or non-Windows platform out there. Unfortunately, log4net does not.
To make things worse, because I was using static initializers for the loggers, the application never even reached the first line of my code and instead crashed with some abstract unhelpful error-dialog, which surely did not help in figuring out what was causing this failure. So in an attempt to get some more helpful feedback, I created this little application-loader to start SharpReader:
static void Main(string[] args) { try { string appName = args[0]; Assembly assembly = Assembly.LoadFrom(appName); assembly.EntryPoint.Invoke(null, null); } catch (Exception e) { Console.WriteLine(e); } }And bang! There was my stacktrace and my cause. From there on the solution was pretty simple - I just created a factory method that wraps the
log4j.LogManager ILog
-factory, which catches the PlatformNotSupportedException
. If the user is running Windows NT/2K/XP, a standard log4net logger is returned, otherwise a simple file-logger is returned that does not use log4net. This file-logger still implements log4net.ILog
though so the clients won't notice any difference and don't need any changes apart from where they create the logger.
Now since all I had was a P166 with a whopping 32Mb of memory to test this, things did run very slow. I know SharpReader now starts and can retrieve feeds on 98/ME, but because of this excruciating slowness, I have not done any extensive testing on it. Please let me know if you run into any further problems on these platforms.
Looks like it's time to pick up a copy of VMWare or VirtualPC. ;)
Posted by Jeff Key at June 25, 2003 11:36 PMConsidering I don't make any money of SharpReader, I'm hesitant to shell out a couple hundred bucks just so I can better test for users with an obsolete OS.
Maybe I should add it to my amazon wish-list though in case one of those users wants to give it to me ;-)
Posted by Luke Hutteman at June 25, 2003 11:43 PMI had this same issue with log4net, and it turns out that the problem is the file watcher. My solution was to catch the exception and still use log4net, but turn off the config file watcher. This seems to work fine.
Posted by Patrick Cauldwell at June 26, 2003 12:17 PMIt would've been nice had this been f**king documented somewhere on the log4net site or their documentation. If it's just the config file watcher though, I may just decide to turn that off and get rid of my simple file-logger.
Thanks for the feedback!
Posted by Luke Hutteman at June 26, 2003 12:48 PMWORA dot net
Interesting post from Luke Hutteman on .Net and Write once, run anywhere. I haven't really played with .Net yet -...
This issue in log4net was fixed in log4net 1.2.0 beta7 (May 2003).
If you have any questions about log4net please post them to log4net-users@lists.sourceforge.net
Thanks
Posted by Nicko Cadell at September 19, 2003 10:46 AMThanks for letting me know Nicko - guess it's about time I upgrade to a new version of log4net anyway ;-)
Posted by Luke Hutteman at September 19, 2003 3:40 PM