Had some problem with gitHub (never used git before), however before of 
pull just take a look at 
https://github.com/marcoCasamento/NHPad/blob/adbf06d51a23d07c58e0cf7d3915d577d523ef45/NHPad.Testbed/Configurator.cs
Obviuously (my fault) the assembly resolution has to take place on the 
AppDomain that actually is requesting it, and LINQPad run queries in 
separate AppDomains, that's why I put this code on the test assembly. 
However, I don't believe that this could be viable for a general purpose 
driver.

Also, can I ask you how do you plan to deal with "Typed Context" that 
Linqpad expects ? I know that in order for intellisense to work, Linqpad 
asks a "typed context", basically a class that expose as many IQueryable<T> 
as your sessionFactory class maps. I've always considered to use the 
DynamicDriver instead of the static one to deal with this, but I'm 
interested to know if other ways exists.

Marco


Il giorno sabato 25 agosto 2012 16:20:43 UTC+2, Diego Mijelshon ha scritto:
>
> I think it is; I remember doing something like that in the past.
>
> I'll be expecting your pull request... :-)
>
>   Diego
>
> On Sat, Aug 25, 2012 at 10:42 AM, Marco Casamento 
> <[email protected]<javascript:>
> > wrote:
>
>> Cloned. I've been able to reproduce the problem, and I've workarounded it 
>> by registering the AppDomain_AssemblyResolve and 
>> returning LoadAssemblySafely("requestedassembly"), assuming the needed dll 
>> is in the same folder of the "client" assembly. Could this be a valid idea ?
>>
>>
>> Il giorno sabato 25 agosto 2012 04:45:21 UTC+2, Diego Mijelshon ha 
>> scritto:
>>
>>> I'm creating an open source LINQPad driver for NHibernate. You can find 
>>> it at https://github.com/diegose/**NHPad<https://github.com/diegose/NHPad>, 
>>> and it's close to being usable. Pull requests welcome.
>>>  
>>> The problem is, I can only get my ISessionFactory to build if the 
>>> "client" assembly (the one containing the session factory building code) is 
>>> located in the driver folder. Otherwise, NH is unable to locate the entity 
>>> class... which is in the same (already loaded) assembly.
>>>
>>> Any ideas?
>>>
>>
>

Reply via email to