Dependencies hell (dll hell all over again).

109 views
Skip to first unread message

Federico Lois

unread,
Jun 27, 2011, 1:16:30 PM6/27/11
to rav...@googlegroups.com
Hi guys,
 
How deep Newtonsoft runs inside RavenDb and how much it is exposed to the normal user? Lately releases of some libraries have been difficultier to keep up for some other projects and suddenly it is getting harder for the end user to manage the complexity of the dependencies. I have been having problems lately with different libraries that use different versions of Newtonsoft that are not as well mainteined as RavenDB with conflicting dependencies. Currently I am facing a dll hell all over again :D
 
I was wondering wouldnt it makes sense to "hide" all support libraries (even at the expense of some memory use) into internal "assemblies" though a postcompile process? Just food for thought.
 
Regards,
Federico
 

Itamar Syn-Hershko

unread,
Jun 27, 2011, 1:29:49 PM6/27/11
to rav...@googlegroups.com
The Newtonsoft Json lib is exposed to the user because this allows for good extension points. Document metadata for example.

Whatever we can we hide (for example Lucene.NET in the server), but most dependencies the client has are actually better exposed.

Federico Lois

unread,
Jun 27, 2011, 1:41:04 PM6/27/11
to rav...@googlegroups.com
I agree extension points are very important and shouldnt be compromised. Currently what I am facing is that both libraries conflict and I have to fork every single time the other library to stay up to date. So far I have been lucky, haven't found many breaking changes, but that is a situation that in the end it would become nastier now that Newtonsoft appears to became the defacto standard for JSON parsing. Maybe rename dependencies dll's so they can coexist with older versions?
 
Regards,
Federico

Itamar Syn-Hershko

unread,
Jun 27, 2011, 1:57:28 PM6/27/11
to rav...@googlegroups.com
I see what you mean, but we rely on nuget packages ourselves whenever possible. Newtonsoft is one of them. So we can't really change assembly names.

In your scenario, maybe this can be resolved by adding RavenDB as a nuget package instead of manually, and letting nuget handle dependencies for you? I never tried working with conflicting dependencies with nuget but it might supports this. See: http://techblog.adrianlowdon.co.uk/2011/03/21/reference-resolution-with-code-analysisfxcop/

Unfortunately I can't see any better way out of this. Perhaps asking the other authors to use nuget as well?

Federico Lois

unread,
Jun 27, 2011, 3:07:50 PM6/27/11
to rav...@googlegroups.com
Actually I dont know if NuGet supports conflicting dependencies, I will ask @haacked about it. Nonetheless, I have not used NuGet version of Raven because more than once I had to use unstable because of bug fixes that I couldnt live without until stable was released. One solution to that is having a NuGet version that publishes both stable and unstable builds (like reactive framework guys are doing with rx-experimental) so it up to the developer to decide when to update and to which version. Needless to say I usually stay on stable, but I had to resort to the fallback before, there is no reason to believe I wouldnt have to do that again; thus why my reluctance to move to nuget for Raven. 
 
Regards,
Federico 

Ayende Rahien

unread,
Jun 28, 2011, 4:04:38 AM6/28/11
to rav...@googlegroups.com
A lot of the fun stuff that you can do with RavenDB require you to touch the JSON.Net dll. Play with serialization, modifying metadata, etc.
We are using the latest stable of Newtonsoft.Json.dll, and any conflicts that occurs can be solved by asking the other projects to upgrade.

Alternatively, since we consider making the json API visible important, maybe you can talk to the other projects and see if you can make them internalize it.

Last, you can always use binding redirects.

fe...@corvalius.com

unread,
Jun 28, 2011, 8:49:43 AM6/28/11
to rav...@googlegroups.com
LOL tried here because this is a well maintained project ;) ... But I agree that the exposure of the XML api is far too important, I didnt know how native Newtonsoft JSON was for writting extensions.

Yesterday I setup binding redirects and so far the only problem I have is that the MSTest runner is not copying the dll .config file so the Moles runner fails on some otherwise correct tests. And yes MSTest sucks but it is the only framework (that I know of) that allows to test Visual Studio extensions. :)

Regards

Sent from my Blackberry


From: Ayende Rahien <aye...@ayende.com>
Date: Tue, 28 Jun 2011 11:04:38 +0300
Subject: Re: [RavenDB] Dependencies hell (dll hell all over again).
Reply all
Reply to author
Forward
0 new messages