Krzysztof Kozmic - All Comments

re: Testing with NHibernate and SQLite

EdgarT — Sat, 20 Mar 2010 19:36:31 GMT

Thomas:

SQLite already support foreign keys.

check it:

www.sqlite.org/foreignkeys.html

re: Making Asynchronous WCF calls without SvcUtil

Steve — Fri, 19 Mar 2010 05:00:15 GMT

I figured it all out.

I didn't add

using Castle.Facilities.WcfIntegration;

so I didn't see the extensions.

Thanks :)

re: Making Asynchronous WCF calls without SvcUtil

Steve — Fri, 19 Mar 2010 04:40:39 GMT

Nevermind, I was looking at server instead of client :)

When injected into a constructor, these async methods are not available ?

How can I use the when injected to resolve with these added calls?

Thanks

re: .NET OSS dependency hell

Steve — Fri, 19 Mar 2010 01:26:26 GMT

My problem is , a facility , ie. wcf is created against a certain version of Windsor. I pull it down, and have to 'magically' figure out which one. Build this, get this, try this, etc..

It's a MESS.

The solution is simple - if you code a product against a particular version then

Does this blog support email notification - I'd like to see if anything comes out of this ?

1. document what you built it against

2. or include the assemblies you used.

Here is example - I am hunting around for the missing interfaces in the current wcf integration build, then I have to figure out how to build the entire castle stack to get the right version.

Then that breaks the mvccontrib castle version, etc.. ad nauseam.

The sad part is -the work done is fantastic. But then it's a major PITA to use it - it's then created more for the guys who made it, not for those trying to simply figure out how to use it.

Please consider this suggestion above - because I'm growing weary of playing 'find the right dll' game.

Great work, wish I could use it :)

re: Making Asynchronous WCF calls without SvcUtil

Steve — Fri, 19 Mar 2010 00:25:17 GMT

how does this work with the wcfintegration in the svc markup?

ie.

Factory="Castle.Facilities.WcfIntegration.DefaultServiceHostFactory

is the svc not needed? this part is confusing - ie. I see your console app , what about a wcf service hosted in iis ?

re: Testing with NHibernate and SQLite

it-crow — Wed, 17 Mar 2010 07:44:48 GMT

thanks for this post. helped a lot.

re: Advanced Castle Windsor – generic typed factories, auto-release and more

Udi Dahan — Sat, 13 Mar 2010 14:44:30 GMT

Krzysztof,

The thing with NServiceBus is that handler invocation needs to be ordered as specified by the application developer. Thus we can't let the container resolve based on the generic type - we need to resolve the specific type.

re: .NET OSS dependency hell

Krzysztof Koźmic — Sat, 27 Feb 2010 10:51:34 GMT

@Paul Cowan

What do you mean by "Common sense and community should also play a factor to try and make some sense of it."?

As Castle team we're pretty open about our release schedule - we publish upcoming release dates as the approach (exact date few weeks before that) castleproject.org/.../projects.html

- we also discuss releases on Castle group so that every member of projects depending on Castle can join the discussion, and talk to us about changes. We're pretty happy to help them with update process, but you know what - hardly anyone ever does that.

- When we were releasing DynamicProxy 2.2 I suggested Fabio (from NHibernate team) to update their bytecode provider to new DP, but he didn't find that necessary. We ship NHibernate with updated bytecode provider as part of ActiveRecord.

Please expand this thought. I meant this post as a means to ignite a discussion, so I'll be very happy to hear your opinion on community/common sense aspect of it.

Social comments and analytics for this post

uberVU - social comments — Fri, 26 Feb 2010 22:36:38 GMT

This post was mentioned on Twitter by huyrua: .NET OSS dependency hell - devlicio.us/.../net-oss-dependency-hell.aspx

re: .NET OSS dependency hell

Robert Rudduck — Fri, 26 Feb 2010 14:44:41 GMT

One of the ways I have managed the non-breaking changes is through using a BindingRedirect. Not always the prettiest solution if you have a bunch of them but it allows you to redirect bindings at runtime to newer assembly versions.

Doesn't fix things when the changes are breaking though...

re: .NET OSS dependency hell

Paul Cowan — Fri, 26 Feb 2010 13:53:03 GMT

@Paul Batum

My point is that maybe with .NET's assembly model, the solution might not be a 100% technical solution. Common sense and community should also play a factor to try and make some sense of it.

As every OSS (horn included) works in a silo the problem will never be fixed.

My point is that attempts like horn will always be swimming up stream with the way things currently are.

Horn's descriptor model takes buy in across the board.

Buy in we did not received.

Jeremy Miller has been posting about providing a gems like experience.

While I applaud the motives, talk is cheap and I simply have no idea how anyone can resolve dependencies as stands without building from the source.

I challenge anyone to come up with a better solution than horn.

Then again, people are busy writing their own IoC containers etc.

re: .NET OSS dependency hell

Paul Batum — Fri, 26 Feb 2010 00:31:44 GMT

To be honest I'm a little confused about Paul Cowan's comment because I thought Horn was supposed to help with these issues. Assuming their aren't any breaking changes, shouldn't Horn rebuild my stack for me when a new castle assembly has a feature I want? What am I missing?

@Keith

http://yuml.me/

@Rik

Why not? Consider: System.Net.Mail.SmtpClient can be found in System.dll

re: .NET OSS dependency hell

Rik Hemsley — Thu, 25 Feb 2010 22:47:31 GMT

I don't see these issues as being a problem with OSS libraries - they're simply the usual day to day issues that arise when dealing with modular systems. Surely even if you use no external libraries in a solution, your own set of projects ends up with a similar structure?

I don't see how reducing the number of assemblies helps at all. Surely EmailSending doesn't belong in Core?

re: .NET OSS dependency hell

Keith Nicholas — Thu, 25 Feb 2010 22:12:16 GMT

what did you use to make your diagrams? :)

re: .NET OSS dependency hell

Scott Bellware — Thu, 25 Feb 2010 21:36:36 GMT

I have a Rails project that uses 15 open source libraries and servers. I don't seem to have this problem. I also don't have that problem when I upgrade apps to new versions of Rails itself. I don't think the problem with dependencies, but with packaging and package management. Maybe the issue with Castle has more to do with packaging technologies. I know that I've had a much easier go at this problem when not using .NET.

Ultimately, the dependency problem is more of a class coupling and versioning problem than an assembly problem. It just so happens that .NET classes are pre-packaged as .NET assemblies. Moving all of the classes into a single assembly solves the assembly problem, but then it just shows that the assembly problem isn't really a problem at all.

The real problem here is that .NET uses static coupling, regardless of whether the coupling is to a virtual type or a non-virtual type. Stop using static coupling and the problem becomes much less problematic.