Castle (Windsor/MR) exceptions on Mono 1.9 but not on 1.2.6

[patrick...@gmail.com]

Does anyone know what might be causing this?

-------

Can't create component 'mr.helperfactory' as it has dependencies to be
satisfied.
mr.helperfactory is waiting for the following dependencies:

Keys (components with specific keys)
- kernel which was not registered.

Castle.MicroKernel.Handlers.HandlerException: Can't create component
'mr.helperfactory' as it has dependencies to be satisfied.
mr.helperfactory is waiting for the following dependencies:

Keys (components with specific keys)
- kernel which was not registered.

at
Castle.MicroKernel.Handlers.DefaultHandler.AssertNotWaitingForDependency
() [0x00000]
at Castle.MicroKernel.Handlers.DefaultHandler.Resolve
(Castle.MicroKernel.CreationContext context) [0x00000]
at Castle.MicroKernel.DefaultKernel.ResolveComponent (IHandler
handler, System.Type service, IDictionary additionalArguments)
[0x00000]
at Castle.MicroKernel.DefaultKernel.ResolveComponent (IHandler
handler, System.Type service) [0x00000]
at Castle.MicroKernel.DefaultKernel.get_Item (System.Type service)
[0x00000]
at Castle.MicroKernel.DefaultKernel.Resolve (System.Type service)
[0x00000]
at Castle.MicroKernel.DefaultKernel.GetService (System.Type
serviceType) [0x00000]
at Castle.Windsor.WindsorContainer.GetService (System.Type
serviceType) [0x00000]
at
Castle.MonoRail.Framework.Container.DefaultMonoRailContainer.UseServicesFromParent
() [0x00000]
at
Castle.MonoRail.Framework.MonoRailHttpHandlerFactory.CreateDefaultMonoRailContainer
(IServiceProviderEx userServiceProvider, System.Web.HttpApplication
appInstance) [0x00000]
at
Castle.MonoRail.Framework.MonoRailHttpHandlerFactory.PerformOneTimeInitializationIfNecessary
(System.Web.HttpContext context) [0x00000]
at Castle.MonoRail.Framework.MonoRailHttpHandlerFactory.GetHandler
(System.Web.HttpContext context, System.String requestType,
System.String url, System.String pathTranslated) [0x00000]
at System.Web.HttpApplication.GetHandler (System.Web.HttpContext
context, System.String url) [0x00000]
at System.Web.HttpApplication+<>c__CompilerGenerated2.MoveNext ()
[0x00000]

[patrick...@gmail.com]

Oh, I should have also said it work on .net

On Apr 18, 10:38 am, "patrick.mce...@gmail.com"

[Rafael Teixeira]

Seems like some change in mono broke compatibility, please post a bug case at Mono's bugzilla. See http://www.mono-project.com/Bugs

Regards from Monoman,

--
Rafael Teixeira
Castle Stronghold

[patrick...@gmail.com]

Thanks but I was mainly wondering if anyone could shed light on the
problem to aid the bug report!

Anyway submitted as is https://bugzilla.novell.com/show_bug.cgi?id=381435

I'm intending to write a test case tomorrow for it.

On Apr 18, 5:42 pm, "Rafael Teixeira"

<rafael.teixe...@castlestronghold.com> wrote:
> Seems like some change in mono broke compatibility, please post a bug case

> at Mono's bugzilla. Seehttp://www.mono-project.com/Bugs

[Matt Robinson]

I've found that for a lot of open source .net projects, there's a
pretty consistent path they've followed when it comes to Mono. When
mono first started supporting most of the M$ corelib stuff, everyone's
all about compatibility to the point of inserting compilation
directives specific to mono or ensuring code blocks would execute in a
consistent manner on both runtimes. As time's passed, I think people
basically decided that it's mono's responsibility to become compliant,
and that .net code should be written without concern for the runtime.

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.

[Ayende Rahien]

Matt,

Did you submit those patches?

In general, there is a desire to run on Mono, but unless I have a concrete need to run this, I am going to be less concerned about this.

[Matt Robinson]

The only patch we've submitted is one to the Npgsql project thus far, because it makes no alterations to the operation of the code block it affects, it just avoids a particular extern call in the mono library that's problematic in 1.9.

Generally speaking, most of the patches we've made end up using utility functions to determine the current operating system and/or runtime.  It's been my assumption that these are not the kinds of things you want to have incorporated into larger public projects, in particular since they are tied to a particular runtime release (in our case, mono 1.9).  Our goal has been to be able to compile without using conditional compilation techniques and have our entire stack work consistently on any combination of framework/os/arch (i.e., compile using mono compiler or m.s. compiler and be able to run resulting libs on either the mono or MS runtimes).

I can review the unsubmitted patches we've made to the Castle project (and Nhib i guess while i'm at it...) and see if any are more applicable long-term, but I expect the majority (if not all) are too closely tied to the current release of the mono runtime.

I personally spend some spare time trying to get the full Castle stack to compile using the mono compiler, though it's been a couple weeks since I've tried.  I'll clearly share if anything comes up.

What are your thoughts on mono compatibility?  Should the project adapt as much as possible to operate consistently in mono, or should it just contain "clean, accurate" code and wait for the mono runtime to catch up?

[Ayende Rahien]

We want to run on mono, but unless someone with interest keeps us honest about it, simple mistakes can make us incompatible.

In general, if there is a simple solution, it is easier to modify the libraries than the runtime, so we would probably accept compatibility patches

[Martijn Boland]

Ayende Rahien wrote:
> We want to run on mono, but unless someone with interest keeps us
> honest about it, simple mistakes can make us incompatible.
> In general, if there is a simple solution, it is easier to modify the
> libraries than the runtime, so we would probably
> accept compatibility patches

My experience with Cuyahoga is that it's almost impossible to keep
things running on Mono, especially because new versions sometimes
introduce new bugs because of refactorings. After spending hours and
hours to stay compatible, I've gotten to the point where I don't invest
much time in it anymore. Luckily, at the moment we have a compatible
version (1.5.2 that runs on Mono 1.2.6), but I haven't tried it on 1.9
and it wouldn't surprise me if it's broken again.

Just my 2 cents

[patrick...@gmail.com]

Well my problem is that I have no choice about moving to 1.9 due to
mod-mono-server stability issues. This is my first "compatibility"
issue (read bug!) with castle/mono. Since this works on 1.2.6 and .net
I don't see how it's anything else but a mono bug and therefore am
holding out for a mono fix.

Matt I agree with what you are saying that there fundamental
differences between linux-windows and this will produce
"compatibility" issues. However mono have committed to producing
compatible code (and why shouldn't it be?) and therefore IMO where,
reasonably possible, it's important to push for a mono fix. I've had
to do a quick hack to use NHiberate Alpha, major issues with
AR .Refresh(), but I still intend to get this ironed out, so I can
remove "//hack:"!!

I am extremely interested in how you got castle compiling on mono. It
would be fantastic if you could share info and tips. Once the hardwork
is done it should be easy to monitor and maintain a fully working
Castle stack on mono.

[Matt Robinson]

Believe me, I feel your pain -- our recent move to mono 1.9 was
motivated by (likely) the same issues with mod_mono_server in 1.2.

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

[Rafael Teixeira]

As a hacker on both projects I'm interested, but time availability is also a concern for me.

I'll try to have Castle Stack compiled/working on my Fedora 8 workstation.

Fun,

--
Rafael "Monoman" Teixeira
---------------------------------------
"I myself am made entirely of flaws, stitched together with good intentions."
Augusten Burroughs

[Joseph Hill]

I've personally had an interest in seeing Castle work well on Mono for
some time.

I would hope that you're not having to maintain too many workarounds
for issues in the Mono runtime, particularly because of bugs. If you
have bug numbers in our bugzilla system (or if you file bugs related
to Castle in the future), please send them to me know so that I can
chase them. Even if you have a "complaint" type bug, hopefully we can
figure out a way to do something about it. If you're uncomfortable
filing the bug, feel free to email me directly.

Finally, if the workarounds are not because of bugs, I would also be
interested in hearing about those as well, just in case we can do
something to alleviate that pain, as well.

Among other goals in this space, I would like to get Castle (as well
as some MonoRail demo apps) packaged as RPMs. We are packaging many
open source .NET applications on the openSUSE build server, and we
ship many of those applications on our openSUSE LiveCD / VMWare
image. Beyond this, if we can get good Castle demos packaged on the
build server, that would make Castle available to our QA team to use
for regression testing.

Thanks
Joseph Hill
Product Manager for Mono
jh...@novell.com

On Apr 18, 9:43 pm, Matt Robinson <robinson.ma...@gmail.com> wrote:
> Believe me, I feel your pain -- our recent move tomono1.9 was

> motivated by (likely) the same issues with mod_mono_server in 1.2.
>
> It's been a while since i've even tried to fully compile the Castle

> stack onmono, I gave up trying to maintain mods for that many months
> back.. Our currentmono-deployed production stack has split-compiled

> binaries -- npgsql, nhibernate, and other accessory libs that we can

> compile onmonoare compiled withmono, 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 onmono). And we all know, those line numbers are quite

> precious when it comes to debuggingmonoissues...
>
> 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 withmonocompilation 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 inmonoto 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"

> whenmonogets "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 inmonono matter what minor change in
> platform you make).
>
> Ideally these bugs should be submitted as test cases tomono. 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
>

> On Apr 18, 2008, at 6:08 PM, patrick.mce...@gmail.com wrote:
>
>
>
> > Well my problem is that I have no choice about moving to 1.9 due to
> > mod-mono-server stability issues. This is my first "compatibility"
> > issue (read bug!) with castle/mono. Since this works on 1.2.6 and .net

> > I don't see how it's anything else but amonobug and therefore am

> > holding out for amonofix.
>
> > Matt I agree with what you are saying that there fundamental
> > differences between linux-windows and this will produce

> > "compatibility" issues. Howevermonohave committed to producing

> > compatible code (and why shouldn't it be?) and therefore IMO where,

> > reasonably possible, it's important to push for amonofix. I've had

> > to do a quick hack to use NHiberate Alpha, major issues with
> > AR .Refresh(), but I still intend to get this ironed out, so I can
> > remove "//hack:"!!
>

> > I am extremely interested in how you got castle compiling onmono. It

> > would be fantastic if you could share info and tips. Once the hardwork
> > is done it should be easy to monitor and maintain a fully working
> > Castle stack onmono.
>
> > On Apr 18, 9:53 pm, Martijn Boland <mart...@boland.org> wrote:
> >> Ayende Rahien wrote:

> >>> We want to run onmono, but unless someone with interest keeps us

[c.sokun]

I hope the successful hacker he get Castle compile and run on Linux
would add an entry to Castle wiki.

[Matt Robinson]

Unfortunately, the company I'm working for is entering it's hectic
season, so I haven't had time to work on the mono compilation stuff.

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

[patrick...@gmail.com]

Likewise sorry for my very delayed response. I have been spending a
lot of time on this recently. I've got Castle building with mono and
it really wasn't that hard at all. However there are quite few tests
failing which relate to bug I originally posted (on mono 1.9.1). I
need to get my head around the MicroKernel before I can build a test
case for the Mono team. It's going to take a while.

Annoyingly I had to do a emergency switch over to windows for 2 big
websites due to a (still) unknown mod_mono issue that came out of
nowhere.

I still urgently need the mod_mono/mono stability of 1.9.x without the
bugs!

P