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 -----Original Message----- From: Thomas Tomiczek [mailto:t.tomiczek@;THONA-CONSULTING.COM] Sent: Donnerstag, 17. Oktober 2002 08:19 To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Possible to change type definition when the type is loaded? Thats not really an option. I do this right now, enforcing the class to be abstract and generating a subclass - thats what I want to get rid of :-) Thomas Tomiczek THONA Consulting Ltd. (Microsoft MVP C#/.NET) -----Original Message----- From: Jason Whittington [mailto:jasonw@;DEVELOP.COM] Sent: Mittwoch, 16. Oktober 2002 22:16 To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Possible to change type definition when the type is loaded? > Simple problem - sort of. I have a toolkit that needs to change type > definitions when the type is loaded. > > Is there any interface where I could "go in between" to change the class > bytecode (for certain methods) while the class is being loaded? In a way > that still goes through the verifier? I'm not aware of a way to do it at classload time but you can hook the IL at JIT time and doctor it up using the profiling interfaces. This is how Jon Lam's CLAW works. Have you thought about dynamically generating classes with System.Reflection.Emit or similar? This might allow you to do some of what you want. Jason 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. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
