Prev: CA2000 Warning call Dispose on object
Next: Hash table with coarse integer keys
From: Peter Duniho on 8 Jun 2010 02:12
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. :)
From: Travis Parks on 8 Jun 2010 18:03
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. 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.
From: Adam Clauss on 8 Jun 2010 21:04
On 6/8/2010 5:03 PM, Travis Parks wrote:
> So if you use direct reflection, it works. If you build something
> using emit, it doesn't. 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.

The runtime needs to care - think about a different scenario:
LibraryA has a reference to, and makes calls to, LibraryB.

After LibraryA has been compiled, the author of LibraryB, for whatever
reason (they are the author after all), decides that a particular method
which used to be public should now be internal (or any other visibility
in which the code from A would not be able to call it.

A new LibraryB.dll is deployed - what should happen? The code from
LibraryA should still work as originally intended, even though LibraryB
now forbids it? That can't happen - while unfortunate for the author of
LibraryA, LibraryB is ultimately what determines which calls can and
cannot be made into it. So, the same exception you are seeing gets
thrown. This particular error cannot be caught at compilation time
unless the author of LibraryA recompiles it against the new LibraryB
(which is NOT a requirement).

So, since there are cases where the compiler cannot check it, the
runtime MUST check it to ensure the proper visibility gets used.

If you think it SHOULD be a requirement that calling libraries must be
recompiled when the libraries they reference change - think about a
patch or service pack to the core .NET Framework. Asking every software
publisher/developer writing .NET code to go recompile their applications
would never work... versioning would become (more of) a nightmare.

-Adam
From: Travis Parks on 8 Jun 2010 21:28
On Jun 8, 7:04 pm, Adam Clauss <cabadam...(a)not.gmail.spam.com> wrote:
> On 6/8/2010 5:03 PM, Travis Parks wrote:
>
> > So if you use direct reflection, it works. If you build something
> > using emit, it doesn't. 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.
>
> The runtime needs to care - think about a different scenario:
> LibraryA has a reference to, and makes calls to, LibraryB.
>
> After LibraryA has been compiled, the author of LibraryB, for whatever
> reason (they are the author after all), decides that a particular method
> which used to be public should now be internal (or any other visibility
> in which the code from A would not be able to call it.
>
> A new LibraryB.dll is deployed - what should happen?  The code from
> LibraryA should still work as originally intended, even though LibraryB
> now forbids it?  That can't happen - while unfortunate for the author of
> LibraryA, LibraryB is ultimately what determines which calls can and
> cannot be made into it.  So, the same exception you are seeing gets
> thrown.  This particular error cannot be caught at compilation time
> unless the author of LibraryA recompiles it against the new LibraryB
> (which is NOT a requirement).
>
> So, since there are cases where the compiler cannot check it, the
> runtime MUST check it to ensure the proper visibility gets used.
>
> If you think it SHOULD be a requirement that calling libraries must be
> recompiled when the libraries they reference change - think about a
> patch or service pack to the core .NET Framework.  Asking every software
> publisher/developer writing .NET code to go recompile their applications
> would never work... versioning would become (more of) a nightmare.
>
> -Adam

You make a good point. However, what causes this scenarios in the
first place? Do these scenarios come up when a dynamic type is working
on types in the assembly that created it?
From: Travis Parks on 8 Jun 2010 21:56
On Jun 8, 7:28 pm, Travis Parks <jehugalea...(a)gmail.com> wrote:
> On Jun 8, 7:04 pm, Adam Clauss <cabadam...(a)not.gmail.spam.com> wrote:
>
>
>
>
>
> > On 6/8/2010 5:03 PM, Travis Parks wrote:
>
> > > So if you use direct reflection, it works. If you build something
> > > using emit, it doesn't. 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.
>
> > The runtime needs to care - think about a different scenario:
> > LibraryA has a reference to, and makes calls to, LibraryB.
>
> > After LibraryA has been compiled, the author of LibraryB, for whatever
> > reason (they are the author after all), decides that a particular method
> > which used to be public should now be internal (or any other visibility
> > in which the code from A would not be able to call it.
>
> > A new LibraryB.dll is deployed - what should happen?  The code from
> > LibraryA should still work as originally intended, even though LibraryB
> > now forbids it?  That can't happen - while unfortunate for the author of
> > LibraryA, LibraryB is ultimately what determines which calls can and
> > cannot be made into it.  So, the same exception you are seeing gets
> > thrown.  This particular error cannot be caught at compilation time
> > unless the author of LibraryA recompiles it against the new LibraryB
> > (which is NOT a requirement).
>
> > So, since there are cases where the compiler cannot check it, the
> > runtime MUST check it to ensure the proper visibility gets used.
>
> > If you think it SHOULD be a requirement that calling libraries must be
> > recompiled when the libraries they reference change - think about a
> > patch or service pack to the core .NET Framework.  Asking every software
> > publisher/developer writing .NET code to go recompile their applications
> > would never work... versioning would become (more of) a nightmare.
>
> > -Adam
>
> You make a good point. However, what causes this scenarios in the
> first place? Do these scenarios come up when a dynamic type is working
> on types in the assembly that created it?- Hide quoted text -
>
> - Show quoted text -

By the way, I did find a workaround: the InternalsVisibleTo attribute.
It is an assembly-level attribute. I can pass to it the name of my
dynamic assembly. I tried it and my unit tests are still passing.

Thanks for everyone's help.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: CA2000 Warning call Dispose on object
Next: Hash table with coarse integer keys