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]> 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]> 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]> > 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]> 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
