16f6c0aecf
Inline adoc files when they are included exactly once. Also fix language tags because this inlining gives us better information on what language the code is written in.
63 lines
2.4 KiB
Plaintext
63 lines
2.4 KiB
Plaintext
== Why is this an issue?
|
|
|
|
Using the ``++base++`` keyword to access a member in anonymous methods, iterator results, and lambda and query expressions results in the compiler creating extra classes under the covers. Those extra classes are "unverifiable", meaning that the under some trust levels, the code will not be allowed to run.
|
|
|
|
|
|
Instead, the access should be made from a helper method.
|
|
|
|
|
|
=== Noncompliant code example
|
|
|
|
[source,csharp]
|
|
----
|
|
public Person GetBasePerson()
|
|
{
|
|
return delegate () { base.GetThePerson(); } // Noncompliant
|
|
}
|
|
----
|
|
|
|
|
|
=== Compliant solution
|
|
|
|
[source,csharp]
|
|
----
|
|
|
|
string BasePerson()
|
|
{
|
|
return base.GetThePerson();
|
|
}
|
|
|
|
public Person GetBasePerson()
|
|
{
|
|
return delegate () { BasePerson(); } // Noncompliant
|
|
}
|
|
----
|
|
|
|
|
|
ifdef::env-github,rspecator-view[]
|
|
'''
|
|
== Comments And Links
|
|
(visible only on this page)
|
|
|
|
=== on 13 Apr 2015, 10:58:02 Freddy Mallet wrote:
|
|
@Tamas, does this rule make sense to you ? Thanks
|
|
|
|
=== on 13 Apr 2015, 11:55:24 Tamas Vajk wrote:
|
|
\[~freddy.mallet] I had to read up on this thing a bit: (\http://blogs.msdn.com/b/ericlippert/archive/2005/11/14/why-are-base-class-calls-from-anonymous-delegates-nonverifiable.aspx) The issue makes sense. BUT I ran the peverify.exe on a sample, and it said that everything is verified, so I believe that this issue has already been solved by the .NET compiler team or by the team who writes peverify.exe. The original post was from 2005.
|
|
|
|
|
|
(I disassembled the generated assembly, and it is still generating additional classes with the same logic as before, so I believe the peverify.exe became more clever.)
|
|
|
|
|
|
In another post \http://blogs.msdn.com/b/ericlippert/archive/2008/11/07/the-future-of-c-part-five.aspx?PageIndex=1#comments, there is a single line of comment from Eric Lippert that says that they solved this problem.
|
|
|
|
=== on 20 Apr 2015, 15:28:01 Ann Campbell wrote:
|
|
\[~tamas.vajk] wouldn't this still be a valid rule for older code?
|
|
|
|
I.E., do we keep the RSpec & set it to inactive by default, or simply close it?
|
|
|
|
=== on 21 Apr 2015, 06:19:09 Tamas Vajk wrote:
|
|
\[~ann.campbell.2] It seems to me that the compiler generated code didn't change. It is still creating extra classes under the covers. So, I think that the peverify.exe became more clever. And this would mean that the rule is only valuable if an old version of the peverify.exe is used. So I would probably close it.
|
|
|
|
endif::env-github,rspecator-view[]
|