DynamicProxy under medium trust

[Martijn Boland]

Last week, there was mentioned that DynamicProxy was supposed to work
under medium trust
(http://support.castleproject.org/projects/DYNPROXY/issues/view/DYNPROXY-ISSUE-52).
I thought to give it a try and build a fresh trunk version, but
unfortunately it still didn't work.

It appeared that DP calls AssemblyBuilder.DefineDynamicModule() with the
flag that also builds debug symbols. This is still not allowed under
medium trust as this still requires
ReflectionPermissionFlag.ReflectionEmit permissions where the rest works
fine since .NET 2.0 SP1
(http://msdn.microsoft.com/en-us/library/76xbchca.aspx).

In ModuleScope.cs, I changed the calls to not generate debug symbols
(see attached patch) and it finally works under medium trust! Also, all
DP tests still pass.
This is huge, because it will also allow NHibernate to run under medium
trust without having to turn off lazy load or use a proxy generator.

Now I wonder if not generating debug symbols has major drawbacks? I am
still able to step into a proxied method of a service (decorated with
ATM attribute) but I have no idea of other side-effects since I know
nothing about the inner workings of DynamicProxy.

Patch is attached.

[Martijn Boland]

After getting DynamicProxy to work under medium trust, I ran into an
issue with Castle.Services.Transaction.
By default it uses CallContext to store the ActivityManager which is not
allowed. By plugging in TLSActivityManager instead of the default
CallContextActivityManager, things now work under medium trust.

But this also raised another issue in web environments: you can't safely
use either CallContext or TLS because a request is not guaranteed to run
in a single thread. IMO, there should also be a
HttpContextActivityManager that stores the ActivityManager in
HttpContext.Current.Items, just like the WebSessionStore in the
NHibernateIntegration facility. And now we're at the
NHibernateIntegration facility: wouldn't it be nice that when you set
isWeb="true", the facility automagically also uses the
HttpContextActivityManager?

Opinions?

[Henrik Feldt]

Sounds like a good idea. Personally I don't mind having a reference to
system.web or just having a conditional compile to compile it into another
assembly referencing system.web. I agree that it would be nice to flip that
switch :). Is this something you are planning on implementing yourself?

Cheers,
Henke

[Tuna Toksoz]

+1

Tuna Toksöz
Eternal sunshine of the open source mind.

http://devlicio.us/blogs/tuna_toksoz
http://tunatoksoz.com
http://twitter.com/tehlike

[Martijn Boland]

Well, Iet's see if I can create a patch for it.

[Martijn Boland]

There is already a patch in donjon for a WebActivityManager:
http://support.castleproject.org/projects/SERVICES/issues/view/SERVICES-ISSUE-11

Any plans to incorporate that one?

[Henrik Feldt]

Hi,

I have finally finished moving properly from England, so I can start looking
into applying the patch for the Transaction management again and also look
into this, ending up with releasing the component.

This weekend I'll be unavailable, but I will finish it off when I get back.
I'll try out the patch as well (I assume it works since it has been created
to solve the problems of thread migrations in the web server).

Regards,
Henrik