Hi Patrick I think you're trying something impossible here. If you expose re-linq's types, you have a dependency. Just making a base class internal and carrying every single protected method forward won't solve the problem. If there really is a change, you're not very likely to be able to hide it from your downstream users using this extremely thin layer. The coupling is already there.
You'd have to create a much more verbose structure to effectively decouple your users from re-linq. That would exclude deriving any public types from our types. In the end, you'll have reinvented the extensibility of re-linq. But what for? re-linq already has the extension system your users need, and more. You just need to make sure that the required parts are accessible through the façade that NH puts around it, and you get a well designed, powerful extensibility pipeline for free. And we're trying to avoid breaking changes too. The last round of changes was done to serve NH, and now we have 2 major providers (NH and our own re-store) building on re-linq, and a few less visible providers, and it works well for all of them. We believe it's very stable now, and none of the plans we have for re-linq will break it. Why would an extensibility pipeline in NH be able to strike a better balance between improvements and backwards compatibility? (The namespace change was an exception, and we only did it because we knew the downstream effects would be pretty tiny. Few people affected, little work to do, no risk of introducing bugs.) Also, I have to say that deriving a public type from an internal type via IL modification is a hack. There's a reason C# won't let you do this. Bottom line: I would keep ILMerge, but remove the /internalize option. Any user who seriously customizes LINQ parsing should be advanced enough to realize they're dealing with another namespace, therefore creating a dependency to a 3rd party library here. And like I said, there's not really a versioning problem here that needs solving either. Cheers, Stefan > -----Original Message----- > From: [email protected] [mailto:nhibernate- > [email protected]] On Behalf Of Patrick Earl > Sent: Friday, April 08, 2011 8:38 PM > To: [email protected] > Subject: Re: [nhibernate-development] ILMerge > > If there is a need to update ReLinq, it's only a matter of taking the > NH the source, putting the new relinq library in the lib folder, > running ShowBuildMenu.bat and selecting F. You can then grab the new > dll from the build folder. As you say, beginners are better off with > the merged assembly anyways. > > Note that we don't just merge everything to make it easy to use. We > merge libraries that are theoretically only used internally. If the > public interface to NHibernate is not sufficient, we will correct > those deficiencies. > > Merging with internalization also allows users to utilize different > versions of libraries with no problems. For example, Antlr is a > popular library, but NHibernate is tied to a particular version. If > you want to use Antlr in your own project without merging, you'd need > to use the same version as NHibernate, which could cause problems. > > Merging also isolates users from changes to these internal libraries, > such as the recent name change of the Remotion.Linq assembly. > > Patrick Earl > > On Fri, Apr 8, 2011 at 12:00 PM, Ramon Smits <[email protected]> > wrote: > > > > > > I hope that we will have builds without ILMerged used for a release > as minor > > updates to dependancies cannot be used because it is merged. > NServiceBus > > made, IMHO, a bad decision by using the ILMerge version as default > release. > > Please don't make that same mistake! I agree that having a ILMerged > version > > is much easier for beginners but its not that you decide to change > all > > dependancies all the time. > > > > -- > > Ramon > >
