I fixed the ExpressionTreeVisitor member visibility explicitly for
now. We'll have to keep our eyes open for other potential issues.
Patrick Earl
On Fri, Apr 8, 2011 at 11:31 AM, Patrick Earl <[email protected]> wrote:
> 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
>>
>
