Prev: CA2000 Warning call Dispose on object
Next: Hash table with coarse integer keys
From: Peter Duniho on 9 Jun 2010 00:23
Travis Parks wrote:
> On Jun 8, 12:12 am, Peter Duniho <NpOeStPe...(a)NnOwSlPiAnMk.com> wrote:
>> Arne Vajh�j wrote:
>>> [...]
>>>> Thanks for looking at this. It is the simplest reproduction of the
>>>> issue I could think of. I am hoping my issue is really simple.
>>> The problem is that you are not using reflection!
>> What he said. :)
>
> So if you use direct reflection, it works. If you build something
> using emit, it doesn't.

That is an incorrect summary of the situation.

If you build something using emit, but fail to emit code that uses
reflection to access the member, it won't work.

If you do it properly, and emit code that uses reflection to access the
member, it will work fine.

> I was thinking about that last night.
> Essentially, I'd have to call MethodInfo.Invoke in the emitted code to
> do what I want. I don't see why the runtime cares. The compiler
> already checks for access. So why should the runtime? Doing reflection
> when I shouldn't have to seems pretty lame.

Just because you generated the code dynamically doesn't mean it doesn't
have to follow all the same rules as any other code.

Pete
From: Peter Duniho on 9 Jun 2010 00:24
Travis Parks wrote:
> By the way, I did find a workaround: the InternalsVisibleTo attribute.

I told you about that workaround in my very first reply.

Glad you "found" it. :)
From: Travis Parks on 9 Jun 2010 18:12
On Jun 8, 10:24 pm, Peter Duniho <NpOeStPe...(a)NnOwSlPiAnMk.com> wrote:
> Travis Parks wrote:
> > By the way, I did find a workaround: the InternalsVisibleTo attribute.
>
> I told you about that workaround in my very first reply.
>
> Glad you "found" it.  :)

That you did, now that you mention it. Reading comprehension...
First  |  Prev  | 
Pages: 1 2 3 4
Prev: CA2000 Warning call Dispose on object
Next: Hash table with coarse integer keys