Hi There are currently no NuGet packs for re-linq that we know of, and we have no immediate plans to create some. I'd suggest you just deliver the assembly with the NH package for now. I don't recommend ILMerge. As you said, it would make it harder for the developer to access re-linq APIs. Also, in case a new, backwards-compatible version of re-linq is released, they'd have to rebuild NH in order to use it (for a separate assembly, binding redirects would do). OTOH, it's quite unlikely that anyone would be using two libraries that bring the re-linq assembly with them.
Cheers, Stefan From: [email protected] [mailto:[email protected]] On Behalf Of Fabio Maulo Sent: Tuesday, January 18, 2011 5:14 PM To: [email protected] Subject: Re: [nhibernate-development] NuGet Package There are cases where the ILMerge may generate more problems than it solve, take care. Where NuGet-packs are not available we can include the DLLs directly. On Tue, Jan 18, 2011 at 1:06 AM, Patrick Earl <[email protected]<mailto:[email protected]>> wrote: Okay, I used ILMerge, internalizing the ReLinq and Antlr assemblies, and aside from one tiny change to a unit test (was checking for a specific Antlr exception), the unit tests still pass. The internalization process avoids conflicts if people choose to use ReLinq or Antlr in their own projects. I propose that we utilize ILMerge to avoid versioning and distribution problems with these two internal-use assemblies. Patrick Earl On Mon, Jan 17, 2011 at 6:51 PM, Patrick Earl <[email protected]<mailto:[email protected]>> wrote: > Does the ReLinq team have any plans to release a package anytime in the > future? > > Are there thoughts around ILMerging ReLinq and Antlr? As far as I'm > concerned, they're basically internal implementation details. > > Patrick Earl > > On Mon, Jan 17, 2011 at 5:00 PM, Fabio Maulo > <[email protected]<mailto:[email protected]>> wrote: >> - Log4Net is unneeded. >> - we have to check the existence of NuGet packages only for Antlr and >> re-linq >> - NH shouldn't have a "default" choice for the bytecode provider because we >> don't want hurt any other OSS project (Castle, Spring, LinFu are in the same >> level of preference for us). Perhaps we may have a default when we will have >> dynamic-proxy included in .NET. >> - As a mature OSS project, and even more thinking in DCVS, the <authors> >> should contain: "look at commits and then add Hibernate committers" >> - The dependency on the NuGet-pack for Castle/LinFu/Spring should be >> related, where possible, only to the DLLs needed by NHibernate and not to >> the whole suite. >> - The NAnt's target named package should includes the execution of a target >> named : NuGetDeploy >> >> >> On Mon, Jan 17, 2011 at 1:53 PM, Patrick Earl >> <[email protected]<mailto:[email protected]>> wrote: >>> >>> I've been thinking about creating a NuGet package for NHibernate and >>> I'm curious if anyone's had any thoughts about this area? >>> >>> As far as I can see, the biggest decision is how to package the >>> different pieces (ex. Castle.ByteCode, Log4Net, etc.). I've been >>> playing with a couple ideas in my head: >>> >>> 1. Have an NHibernate.Core package that includes on the basics, then >>> have things like NHibernate.Castle, NHibernate.LinFu, >>> NHibernate.Log4Net that add on the extra pieces. >>> 2. Have an NHibernate package that includes all the bytecode >>> providers and configures Castle by default. >>> >>> Thoughts? >>> >>> Patrick Earl >> >> >> >> -- >> Fabio Maulo >> >> > -- Fabio Maulo
