You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I just learned that there is a way to avoid most if not all of run time reflection code in the codegen'ed serializers by accessing private fields directly. The trick is to suppress member visibility checks at compile and run time (via different mechanism). Roslyn supports that for scenarios like debugging.
As I understand, instead of generating the following code
An immediate issue I see with this is that today we add generated code to the target grain interfaces/classes assemblies. This will suppress visibility checks for app code, which is obviously undesirable. I'll open a separate issue to discuss the fact that we don't really have to include generated code back to app projects. Interestingly, this approach should work right away for run time codegen.
The text was updated successfully, but these errors were encountered:
The easiest path to explore this I think is to microbenchmark it first. Then we could try it for run time codegen, which wouldn't require any change to the compile time path.
This simplifies our code and makes it easier to support .NET Native and other AOT systems where reflection and runtime IL generation is restricted. It would be nice if we could do it on a per-class basis.
I just learned that there is a way to avoid most if not all of run time reflection code in the codegen'ed serializers by accessing private fields directly. The trick is to suppress member visibility checks at compile and run time (via different mechanism). Roslyn supports that for scenarios like debugging.
As I understand, instead of generating the following code
we could simply generate
The 'magic' that is required at compile time is to set two internal properties of
CSharpCompilationOptions
.At run time a special internal attribute is required to suppress visibility checks. We'd need to generate it for every assembly.
An immediate issue I see with this is that today we add generated code to the target grain interfaces/classes assemblies. This will suppress visibility checks for app code, which is obviously undesirable. I'll open a separate issue to discuss the fact that we don't really have to include generated code back to app projects. Interestingly, this approach should work right away for run time codegen.
The text was updated successfully, but these errors were encountered: