Okay, ignore the crazy remark about the built-in expression visitor... was thinking it was the other type.
On Fri, Apr 8, 2011 at 11:01 AM, Patrick Earl <[email protected]> wrote: > Hi Stefan. > > Thanks for the heads up. Unfortunately we're not using .NET 4, so we > can't just switch to the built-in expression visitor. I'll take a > look at which Relinq classes we derive from and think about this for a > bit. > > Patrick Earl > > On Fri, Apr 8, 2011 at 9:13 AM, Wenig, Stefan <[email protected]> wrote: >> Hi all >> >> >> >> I guess the limitations that ILMerge brings are beginning to show: >> >> http://groups.google.com/group/nhusers/browse_thread/thread/25c6865b9a846963 >> >> >> >> I’d assume /internalize was used to allow users to use NH and another >> version of re-linq in the same project? In this case I’d argue they’d >> probably not be using re-linq for anything related to NH, so they might as >> well create two assemblies that reference NH and re-linq respectively. >> Shouldn’t happen too often anyway. >> >> >> >> So my suggestion would be to remove /internalize. >> >> >> >> Stefan >> >> >> >> >> >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Wenig, Stefan >> Sent: Thursday, January 20, 2011 12:37 PM >> To: [email protected] >> Subject: RE: [nhibernate-development] NuGet Package >> >> >> >> 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]> 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 >
