Unfortunately for most "cross platform" .net coders, it means that if
something works on M$ and not on mono, we are left with three choices:
patch mono, patch the particular lib that's causing the issue, or
insert hacks into our own "end-code". I personally prefer the second
option, as managing deployments and updates of a patched mono stack is
very headach-y, and the third option doesn't always solve the problem.
Our current deployment uses both windows and linux servers, running
the .net runtime and the mono runtime, respectively. We've patched
everything from npgsql to nhibernate to prevalence, to portions of the
castle stack in order to have consistent behavior across both
runtimes. And it ain't been easy. There are even inconsistent
behaviors in mono when you switch OS and/or cpu architecture (check
out how DateTime.ParseExact("somedate").Ticks has different results
for the same string when run on windows-mono1.9 or, say, opensuse-
mono1.9).
So basically it appears to me at this point that if you're going for
mono, and you run into a situation where you get unexpected behavior
just from switching runtimes, you're close to sh*t out of luck for
support from most open source projects. I'm 100% sure that mono will
continue to grow, and these oddities will eventually disappear. But
if you're pushing the envelope dev-wise, you should expect that things
will be a little more difficult.
I've said all this also because I'm curious about what others think
about mono compatibility -- in the sense of modding code to behave
consistently when it's obviously a runtime issue. I've considered
setting up a repository of the code mods we and some others have made
to perhaps promote sharing compatibility patches... but maybe people
are more comfortable waiting for mono updates? What is the official
"Castle Team" stance on mono?
matt
btw -- We still don't have the entire Castle stack (we usually stick
pretty close to trunk) even compiling using the mono compiler. We
*are* passing all unit tests when executing them using the mono
runtime though.
Just my 2 cents
It's been a while since i've even tried to fully compile the Castle
stack on mono, I gave up trying to maintain mods for that many months
back.. Our current mono-deployed production stack has split-compiled
binaries -- npgsql, nhibernate, and other accessory libs that we can
compile on mono are compiled with mono, but the castle stack is build
using the ms compiler, then finally, our own libs are coded ground up
for compatibility for both *compilers*. The result is almost amusing
at times -- published exceptions contain line number references for
only certain portions of the stack (if the production code was being
executed on mono). And we all know, those line numbers are quite
precious when it comes to debugging mono issues...
I'll see if I can't free up some resources (or spend some of my own
time) to see where we're at again with mono compilation of the Castle
stack. The big problem we found last time are all of those nutty bugs
that show up even though everything compiles successfully, and our
unit tests pass. We actually have a unit test lib we've started now
that pokes at particular bugs we've found in mono to help ease
transitional periods like 1.2 to 1.9 in the future. Which is an
entertaining test suite to have -- these tests will actually "fail"
when mono gets "fixed"....
I'll keep you posted with what happens, but I can't for sure promise
that we'll be able to get everything to work again. What revision of
castle are you using? It'd be nice if it was relatively close to
trunk, since we try to stay no more than a couple dozen commits
behind... Also, is there a particular linux flavor (or other OS) that
you're using? We've build machines and/or VM's for a couple, but
they're particular to our production environment (and as i mentioned,
tiny strange things happen in mono no matter what minor change in
platform you make).
Ideally these bugs should be submitted as test cases to mono. Are
there portions of the castle stack already submitted as such? From my
own experience, it can be a little hard to spend the time finding a
bug, apply your patch to your own work, and then find the time to go
back and write a proper bug report to the appropriate project host.
And I'm a fan of giving back -- in my experience though you have a
greater impact if you spend the time including unit test samples and
specific patches than just submitting those "complaint" style bug
reports...
Do any others have interest/problems/comments in this area? I'd like
to keep an open discussion but don't feel the need to unnecessarily
clog a list if it's just me + patrick trying to solve something too
particular to ourselves.
matt
I will say that I can forsee some issues having to do with versioning
-- there are breaking changes in certain libraries which we are using
(particularly, npgsql and nhibernate), and we use the 1.9 release of
mono (at least somewhere in our production stack we're not using
compiled-from-source libraries... heh). What is the best way to
handle these things? Does Castle have a protocol for support library
updates (like nhibernate bugfixes)? Is there a plan for a Castle
release in the near future? I believe mono already packages some of
the libs used (for example npgsql), but there are changes to even that
lib we've had to make... What's the protocol for those sorts of updates?
I should have much more time in the coming weeks to start submitting
all the bug reports/patches we've made. I apologize for the delay,
but I gots ta get paid!
matt