how to reference internal classes from generated code in C#?

  • Thread starter Thread starter bob_jenkins
  • Start date Start date
B

bob_jenkins

C# allows code to be generated, but the generated code is in its own
assembly. Is there a way for that generated code to access internal
classes in the assembly that produced it? To have the generated code
pretend to be part of the assembly that produced it? Maybe some
compilation option? I want the generated code for efficiency, but I
don't want to pay for it by making all sorts of classes public that
would otherwise be internal.
 
I think you need to rephrase the question, with a code example. I'm lost as
to what you want...
 
C# allows code to be generated, but the generated code is in its own
assembly.  Is there a way for that generated code to access internal
classes in the assembly that produced it?  To have the generated code
pretend to be part of the assembly that produced it?  Maybe some
compilation option?  I want the generated code for efficiency, but I
don't want to pay for it by making all sorts of classes public that
would otherwise be internal.
Click to expand...

First, you may want to be more specific about how having generated code  
makes things more efficient.  It's possible that your efficiency gain  
isn't as great as you might think, or that there is an equivalent strategy  
that can be used that achieves similar efficiency without run-time code  
generation.

Beyond that, I admit I know next to nothing about classes like  
CSharpCodeProvider and there may in fact be some approach you can take to 
cause generated code to effectively be in a given assembly.  But it seems  
unlikely to me, because of the difficulty in ensuring that the code is  
actually being compiled by the assembly it wants to be in.  That is, if 
you could specify an arbitrary assembly for compilation, some other code  
could insert code into an assembly.

There might be some sort of trusted code rules that address that, but it  
does seem like a potential code safety hole.

However, there are in fact strategies that can be used to get at internal 
and even private members of an arbitrary class.  The messiest is  
reflection.  Used carelessly, you can kill performance with reflection, 
but if you know what you're doing you can use it to get at any member of  
any type, including internal and private ones.

An approach that is probably more kosher is to use the  
[InternalsVisibleTo] code attribute in the assembly that contains the  
internals you want to make accessible, specifying the name of the assembly  
you will be generating dynamically.  See  http://msdn.microsoft.com/en-us/library/0tke9fxk.aspxfor more details.

This last suggestion does of course assume that using a CodeProvider  
implementation you can name the assembly you're compiling.  That seems  
like a reasonably expectation to me, but given my lack of experience with 
it, I can't say for sure whether it'd work.

Pete
Click to expand...

Thanks for the pointer ...

If I read it right, normally friend assemblies are compiled and signed
with a private key locally, then sent to users. That works. But in
my case I want the users to run my code, which will generate code,
which would need to be compiled and signed. That requires shipping a
private key to users. That won't work. I'll live with some extra
classes being public, then.
 
Back
Top