Ok, that's great to know. Thanks.

/Johannes

On Mon, Aug 2, 2010 at 12:51 PM, Fabio Maulo <[email protected]> wrote:

> No thanks.
> We are enough in touch with Castle prj.
> The BytecodeProvider is in a different assembly for some reason.
> As you can see, we are already using the last released DynamicProxy
> 2.2.0.6628.
> In the Castle's Download page I can't see anything new.
>
> When/if there will be something new we will update our library; if it
> happen after our GA you can compile the Castle.Bytecode by yourself and/or,
> where really needed, we can release a new NHibernate.ByteCode.Castle
>
> AFIK, Krysztof is planning a new stand-alone DynamicProxy assembly.
>
> On Mon, Aug 2, 2010 at 6:00 AM, Johannes Gustafsson 
> <[email protected]>wrote:
>
>> Hi,
>>
>> Have you considered upgrading NHibernate.ByteCode.Castle to use Castle 2.5
>> before releasing NH3.0?
>>
>> Castle.Core version 2.5 is now in beta and seems to be released pretty
>> soon. One thing that is new is that DynamicProxy is now merged into
>> Castle.Core and is no longer a separate assembly. Therefore it requires
>> changes in the project to not use the castle.dynamicproxy2.dll anymore. I
>> dont know if the new version contains any features that are of use for NH
>> but if I was using castle in my codebase and wanted to upgrade to 2.5 then I
>> would have to have to patch NHibernate.ByteCode.Castle and compile my own
>> version of it.
>>
>> I can think of 2 solutions:
>>
>> 1. Have 2 versions of NHibernate.ByteCode.Castle. One compiled with 2.1
>> and one compiled with 2.5. The user would then pick the one they want.
>> 2. ILMerge Castle into NHibernate.ByteCode.Castle and internalize it. That
>> way it won't conflict with other Castle libs used in the users codebase.
>>
>> I can probably create a patch for it, I just wanted to see if anyone else
>> has thought about this and what the "right" way would be.
>>
>> Regards,
>> Johannes
>>
>
>
>
> --
> Fabio Maulo
>
>

Reply via email to