You need to demand ReflectionPermission with ReflectionEmit enabled. That's, for instance, not grantable for the default "Internet" permission set.
-cv -----Original Message----- From: Thomas Tomiczek [mailto:t.tomiczek@;THONA-CONSULTING.COM] Sent: Donnerstag, 17. Oktober 2002 14:55 To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Possible to change type definition when the type is loaded? You are right - the request is about smuggling object persistence in. Basically trying to get rid of the abstract properties and the abstract requirement for the base class. Though it sounds like this will have to wait, then. BTW - reflection.emit can be used to genrate assemblies dynamically even with very low security rights, to my knowledge - the resulting code just needs to pass the verifier. Thomas Tomiczek THONA Consulting Ltd. (Microsoft MVP C#/.NET) -----Original Message----- From: Clemens F. Vasters [mailto:clemensv@;NEWTELLIGENCE.COM] Sent: Donnerstag, 17. Oktober 2002 14:37 To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Possible to change type definition when the type is loaded? Thomas, I went through that long time ago and the result was that there is basically no way to get this going without sacrificing too much of the programming model (constructing instances with "new", etc.) or without having to make too many preconditions in terms of full trust security and the likes. One thing I tried was to smuggle wrapped classes into the activation chain for context-bound objects, but the activation logic is smart enough to figure out whether there's type spoofing going on under the hood (which is a Good Thing for security). Based on a couple of "Daikiri" snippets you've been posting here over time, I think I have an impression of what you are trying to do: smuggling automatic object persistence into the code, for instance. Coincidentally, I just dug out one of my earlier .NET lab-projects from back in late 2000 whose programming model looks strikingly similar. Based on what I found back then, the Framework just won't let you do what you are trying to do and eventually abandoned that path (I will look at this again once generics come around with all bells and whistles) You may want to look at a purely interception-driven design that is driven by attributes on the class, but doesn't require any of the infrastructure code be part of the class. Remoting's object-sink is one option here. Another option is to extend things at compile time using a metadata-driven "post-compiler" that feeds off the compiled metadata and code-generates the actual classes that the clients bind to. That's basically the ASP.NET approach and makes most sense. What needs to be considered with all this is that the code being executed may run with lowered trust and restricted client permissions. Hence, invoking Reflection.Emit or any of the compilers *during a call or during JIT* (opposed to ASP.NET's "before handling an entire web request") will just not work in production environments. My 2c -cv You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
