ILMerge-ing of raven assemblies about neventstore HOT 3 CLOSED

I've gone back and forth on this particular point quite a bit. The same could be said regarding the MongoDB implementation as well as any future implementations. There are basically three options:

1. ILMerge and internalize everything
2. ILMerge, but don't internalize
3. Don't ILMerge the assembly at all.

There are different pros and cons to each step. The current strategy is to merge but leave them visible so that you can access the full power of the Raven client code. If I internalize you don't get that and you're limited but it can cause conflicts.

I've got two ideas on the matter:

1. Internalize it but provide enough knobs to make it configurable.
2. Don't internalize so that it can use the implementation in the bin directory and the caller has all of the advanced options available.

Thoughts?

from neventstore.

My preference is to not ILMerge at all (option 3). I think having classes public from multiple assemblies (option 2) causes too many problems, conflicts and confusion and makes working with EventStore more difficult than it should be (more of a .NET issue though). I'm using MongoDB in other parts of the app and end up 'referencing' it from the one in the EventStore assembly which doesn't feel right.

I'm not sure how MongoDB would handle the serialization registration with (option 1) - it may cause issues, I'd have to look into it more but that would be my second choice option.

I think all that the ILMerge really gives you is a distribution that appears a little tidier and removes any issues where specific versions of the drivers may be required. The worst case (again, with MongoDB) is that the driver is updated to support some new feature of MongoDB (but doesn't impact EventStore) and because it's ILMerged it means I need to start re-building the EventStore and CommonDomain to update the driver which is the main reason I'd like to have it separate.

I'm sure I'm doing it wrong and should be able to sort out the referencing and have different driver versions in use at the same time but then I risk hitting issues with the serialization.

from neventstore.

I tend to agree with CaptainCodeman.

ILMerging external dependencies makes it easy to add the right reference to the project - especially for new users, results in less assemblies but when you hit the wall of conflicts between them it's not fun anymore.

ILMerging only main project with it's dependent projects and no external dependencies gives you most of the good parts without the bad parts. Adding a conditional reference to a .cproj is a pain (i've learned how to do it from your prjs, thanks) but you don't have to do it every day.

Not merging assemblies with external, common, dependencies (Raven,Mongo,NHibernate) will probably cause the least amount o trouble on the long run.

I think that having a build script for unmerged assemblies might be usefull.

Thanks for your time,
Iulian

from neventstore.