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

[bob_jenkins@burtleburtle.net]

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.

[Family Tree Mike]

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

I think you need to rephrase the question, with a code example. I'm lost as
to what you want...

<bob_jenkins@bu rtleburtle.netw rote in message
news:7f14c0a9-defe-4f98-9994-3753f6c1f0b4@e3 8g2000prn.googl egroups.com...

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.

[Peter Duniho]

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

On Mon, 13 Oct 2008 16:48:04 -0700, <bob_jenkins@bu rtleburtle.netw rote:

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.

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
CSharpCodeProvi der 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
[InternalsVisibl eTo] 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.aspx for 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

[Family Tree Mike]

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

Never mind. Peter's interpretation seems to make sense now...

"Family Tree Mike" <FamilyTreeMike @ThisOldHouse.c omwrote in message
news:eja7FOZLJH A.3808@TK2MSFTN GP04.phx.gbl...

>I think you need to rephrase the question, with a code example. I'm lost
>as to what you want...
>
<bob_jenkins@bu rtleburtle.netw rote in message
news:7f14c0a9-defe-4f98-9994-3753f6c1f0b4@e3 8g2000prn.googl egroups.com...

>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.

>

[bob_jenkins@burtleburtle.net]

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

On Oct 13, 6:08 pm, "Peter Duniho" <NpOeStPe...@nn owslpianmk.com>
wrote:

On Mon, 13 Oct 2008 16:48:04 -0700, <bob_jenk...@bu rtleburtle.netw rote:

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.

>
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  
CSharpCodeProvi der 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  
[InternalsVisibl eTo] 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/libr...ke9fxk.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

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.