本文是小编为大家收集整理的关于具有“内部保护”和派生的奇异性的处理/解决方法，可以参考本文帮助大家快速定位并解决问题，中文翻译不准确的可切换到English标签页查看源文。
问题描述
我正在重构一些代码以将一些基类移动到一个单独的
部件.这些基类之一有一个成员属性是
''受保护的内部''.但是，当我将这些基类移到另一个
汇编，编译器抱怨派生类中的覆盖，
也声明为"受保护的内部"，正在尝试更改访问权限
从"受保护"修改而来，显然不是这样.(我查过了
程序集中的元数据和基类属性是"famorassem".)
如果我将派生类声明更改为"受保护"，它可以正常工作.
任何人都可以解释为什么它会以这种方式工作?
推荐答案
编译器消息不清楚，但我认为您遇到了错误
因为你有一个可见性冲突.
当你有"受保护的内部"驻留的类 C1 中的方法 F
在程序集 A1 中，F 对任何地方的 C1 派生类都是可见的，此外
A1的所有课程.
现在，当您将派生类 C2 放入覆盖 F
的程序集 A2 中时使用相同的受保护的内部修饰符，覆盖仍然是
对任何地方的派生类可见——但它也是可见的
整个 A2(但不是 A1)，而原始方法是可见的
贯穿 A1(但不是 A2).
现在如果 A2 中的某个非 C2 方法有一个 C1 对象并尝试调用 F，
它应该得到什么方法?它不能得到 C1.F 因为那是
在 A1 内部，它无法获得 C2.F，因为它受 C2 保护.
对于 A1 中具有 C2 对象的非 C1 方法也是如此.
在我看来，除了
之外，不应使用受保护的内部内部类.用
暴露一个类是自找麻烦保护其他程序集的内部方法.
--
http://www.kynosarges.de
"克里斯·纳尔"<di******@kynosarges.dewrote 在消息中
新闻:hb********************************@4ax.com...
它无法获得 C2.F，因为它受 C2 保护.好吧，这就是编译器正在做的事情，问题是它为什么要这样做.
如果框架允许覆盖也是"受保护的内部"
那么它*可以*得到 C2.F.问题是，框架到底是什么鬼
通过坚持更改派生中"受保护"的访问权限来防止
班级.我无法理解.
对于 A1 中具有 C2 对象的非 C1 方法也是如此.这意味着程序集的循环引用.
在我看来，除了同意 - 我自己不会这样设计，我正在重构
之外，不应使用受保护的内部内部类.用
暴露一个类是自找麻烦保护其他程序集的内部方法.
别人的代码.编译器的行为只是一个真正的 PITA
这样是因为这意味着我还要重构几十个
由于移动基类而从该基类派生的类
你好，
好吧，这就是编译器正在做的事情，问题是为什么会这样它可以防止你??broadeninga??能见度.以前那个方法是
正在做.如果框架允许覆盖也是
''protected internal'' 那么它*可以*获得 C2.F.问题是，什么
evil 是通过坚持改变访问来防止的框架
在派生类中"受保护".这是我无法理解的.
对 A1 程序集中的任何类型都可见.如果您将其覆盖为??protected
internala??，你也会让它对 A2 程序集可见，这是不一致的.
一个??受保护的内部??(a??[visible to] family or assemblya?? in .NET)实际上是
一个??受保护的或内部的??.你不能覆盖一个??internala??另一个成员
程序集，但你可以覆盖一个??protecteda???.当你覆盖 a??protected
内测??成员，它是一个??内部??存在的一部分是一个??遗留在
A1 程序集的基类a??，只是a??protecteda??部分留给
这意味着程序集的循环引用..NET 哪个可以，为什么不呢?
同意 - 我自己不会那样设计的，我正在重构某人else 的代码.这只是一个真正的 PITA，编译器的行为方式是这样的
因为这意味着我还要重构几十个派生类
由于将基类移动到不同的
，因此从这个基类
重构工具可以为您处理，但我当然不能
请确保，因为我不知道您的类层次结构.
(H) 谢尔盖
问题描述
I am refactoring some code to move some base classes into a separate
assembly. One of these base classes has a member property which is
''protected internal''. However when I move these base classes to another
assembly, the compiler complains that the override in the derived class,
also declared as ''protected internal'', is trying to change the access
modified from ''protected'', which is clearly not the case. (I have checked
the metadata in the assembly and the base class property is ''famorassem''.)
If I change the derived class declaration to just ''protected'', it works OK.
Anybody have an explanation as to why it is working this way?
推荐答案
The compiler message is unclear but I think you''re getting an error
because you have a visibility conflict.
When you have "protected internal" method F in class C1 which resides
in assembly A1, F is visible to C1-derived classes anywhere, plus to
all classes in A1.
Now when you put a derived class C2 in assembly A2 that overrides F
with the same protected internal modifier, the override is still
visible to derived classes anywhere -- but it''s also visible
throughout A2 (but not A1) whereas the original method is visible
throughout A1 (but not A2).
Now if some non-C2 method in A2 has a C1 object and tries to call F,
just what method should it get? It can''t get C1.F because that''s
internal to A1, and it can''t get C2.F because that''s protected to C2.
Same for a non-C1 method in A1 that has a C2 object.
In my opinion, protected internal should not be used except with
internal classes. It''s asking for trouble to expose a class with
protected internal methods to other assemblies.
--
http://www.kynosarges.de
"Chris Nahr" <di******@kynosarges.dewrote in message
news:hb********************************@4ax.com...
and it can''t get C2.F because that''s protected to C2.Well that''s what the compiler is doing, the question is why it is doing it.
If the framework allowed for the override to be also ''protected internal''
then it *could* get C2.F. The question is, what evil is the framework
preventing by insisting on changing the access to ''protected'' in the derived
class. This I cannot understand.
Same for a non-C1 method in A1 that has a C2 object.Which would mean a circular reference of assemblies.
In my opinion, protected internal should not be used except withAgreed - I wouldn''t have designed it that way myself, I''m refactoring
internal classes. It''s asking for trouble to expose a class with
protected internal methods to other assemblies.
someone else''s code. It''s just a real PITA that the compiler is behaving
this way because it means that I also have to refactor the several dozen
classes derived from this base class as a result of moving the base class
into a different assembly.
Hello,
Well that''s what the compiler is doing, the question is why it isIt prevents you from a??broadeninga?? the visibility. That method used to be
doing it. If the framework allowed for the override to be also
''protected internal'' then it *could* get C2.F. The question is, what
evil is the framework preventing by insisting on changing the access
to ''protected'' in the derived class. This I cannot understand.
visible to any types in the A1 assembly. If you override it as a??protected
internala??, you''ll make it visible to the A2 assembly too, which is not consistent.
a??protected internala?? (a??[visible to] family or assemblya?? in .NET) is actually
a??protected or internala??. You cannot override a??internala?? members in another
assembly, but you can override a??protecteda??. When you override a a??protected
internala?? member, its a??internala?? part of the existence is a??left behind in
the base class in the A1 assemblya??, just the a??protecteda?? part is left for
you to override.
Which would mean a circular reference of assemblies.Which is just OK with .NET, why not?
Agreed - I wouldn''t have designed it that way myself, I''m refactoring someoneelse''s code. It''s just a real PITA that the compiler is behaving this way
because it means that I also have to refactor the several dozen classes derived
from this base class as a result of moving the base class into a different
assembly.
A refactoring tool could have handled that for you, but of course I cannot
be sure as I don''t know your class hierarchy.
(H) Serge
更多相关问答
联系站长