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
