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

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

[Family Tree Mike]

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

<bo*********@burtleburtle.netwrote in message
news:7f**********************************@e38g2000 prn.googlegroups.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]

On Mon, 13 Oct 2008 16:48:04 -0700, <bo*********@burtleburtle.netwrote:

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

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

"Family Tree Mike" <Fa************@ThisOldHouse.comwrote in message
news:ej**************@TK2MSFTNGP04.phx.gbl...

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

<bo*********@burtleburtle.netwrote in message
news:7f**********************************@e38g2000 prn.googlegroups.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]

On Oct 13, 6:08*pm, "Peter Duniho" <[e-mail]>
wrote:

On Mon, 13 Oct 2008 16:48:04 -0700, <[e-mail]:

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