| Su | Mo | Tu | We | Th | Fr | Sa |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 |
Browse archives
|
WHY MONO IS NOT YET READY FOR MY BALLSI've been working with .NET lately, first with JScript .NET, and now with C#. I'm writing a simple, simple application that does some stuff, and can run either on the command line, or via some Windows scheduling mechanism. I.e., either as a service or using Windows Scheduler.
There's this great property called System.Environment.UserInteractive in .NET that tells you if the application was executed interactively. This is a great opportunity to decide where to dump the output of your application. If it's true, spew to System.Console. If it's false, write to a file or, in the case of Windows, to the beautiful, beautiful Event Log, available via System.Diagnostics.EventLog, even -- no work necessary! I wrote this application, and it got to a pretty solid point, where I wanted to try running it on mono. I installed the clever Mac version, since it was easy peasy, compiled my app, ran it, and pfft. Nothing.
Why's that? I had one of those little suspicions, which was borne out by downloading the source:
[MonoTODO]
public static bool UserInteractive {
get {
return false;
}
}
Sure, there are easy-enough ways to get the same information, or I can even make a command-line flag, but mono is above a 1.0 release. They're working on 2.0! I would have thought one of the targets of a 1.0 release would be "have all the basic class libraries complete", but I guess that's why I do commercial software. At least I can hide this stuff from the rest of the world. :-) Post new comment |
SearchSimilar entriesUser login |