[英]Internal classes having the same namespaces but in different assemblies?
Basically I have a CS file defining an internal class, then I copy to various of CS projects. 基本上我有一个定义内部类的CS文件,然后我复制到各种CS项目。 And the assemblies of these CS projects will be loaded in an application.
并且这些CS项目的程序集将加载到应用程序中。 The program seems to be running just fine.
该程序似乎运行得很好。
However, having multiple classes with the same class name in the same namespace make me feel uneasy even if they are internal within each assembly. 但是,在同一名称空间中具有相同类名的多个类使我感到不安,即使它们在每个程序集内部也是如此。
Is a class uniquely identified through class name, namespace as well as assembly in an AppDomain? 是通过类名,命名空间以及AppDomain中的程序集唯一标识的类吗?
Is a class uniquely identified through class name, namespace as well as assembly in an AppDomain?
是通过类名,命名空间以及AppDomain中的程序集唯一标识的类吗?
Short answer: yes. 简短回答:是的。
Longer answer: 更长的回答:
There are a few subtle points to consider. 有一些微妙的要点需要考虑。
First, from the CLR perspective there is no such thing as a "namespace". 首先,从CLR的角度来看,没有“命名空间”这样的东西。 The name of the string type is
System.String
as far as the CLR is concerned. 就CLR而言,字符串类型的名称是
System.String
。 So it is more accurate to say that from the CLR perspective, a type is uniquely identified by its name and assembly. 因此,更准确地说,从CLR的角度来看,类型由其名称和程序集唯一标识。
Second, types may be nested. 其次,类型可以嵌套。 So types are actually uniquely identified by their name, containing type (if there is one) and assembly.
因此,类型实际上由其名称唯一标识, 包含类型 (如果有)和汇编。
Third, types may be generic. 第三,类型可以是通用的。
Foo.Bar
and Foo.Bar<T>
are different types. Foo.Bar
和Foo.Bar<T>
是不同的类型。 So types are identified by their name, containing type, assembly, and generic arity. 因此,类型由其名称标识,包含类型,程序集和通用arity。
Fourth, and this is the weird one, the CLR considers types in assemblies loaded with Load
different than types in the same assembly loaded with LoadFrom
. 第四,这是奇怪的,CLR认为加载
Load
程序集中的类型与加载LoadFrom
的同一程序集中的类型不同。 You can end up with situations where the CLR tells you that type Foo in assembly Bar is not compatible with type Foo in assembly Bar, and boy, is that confusing. 你最终可能会遇到CLR告诉你程序集栏中的类型Foo与程序集栏中的类型Foo不兼容的情况,而男孩,这是令人困惑的。
While it makes things confusing all your internal classes only exist in their respective assemblies so they are autonomous and will not be seen by the other classes in the other assembly. 虽然它会使事情变得混乱但是所有内部类只存在于它们各自的程序集中,因此它们是自治的,并且不会被其他程序集中的其他类看到。
But from a maintenance and simplicity perspective it should be put at the top of the house keeping tasks. 但从维护和简单的角度来看,它应该放在房屋保持任务的顶端。
Yes, the CLR uses the assembly to identify each type. 是的,CLR使用程序集来识别每种类型。 If you compile a simple Hello World app and look at the IL:
如果您编译一个简单的Hello World应用程序并查看IL:
.method private hidebysig static void Main(string[] args) cil managed
{
.entrypoint
// Code size 13 (0xd)
.maxstack 8
IL_0000: nop
IL_0001: ldstr "Hello world"
IL_0006: call void [mscorlib]System.Console::WriteLine(string)
IL_000b: nop
IL_000c: ret
} // end of method Program::Main
You can see how System.Console is referred to by including the assembly, namespace, and class names. 您可以通过包含程序集,命名空间和类名来查看System.Console的引用方式。 However, if you are referring to a type in the same assembly, the assembly name can be implied, eg:
但是,如果您在同一个程序集中引用类型,则可以隐含程序集名称,例如:
.method private hidebysig static void Main(string[] args) cil managed
{
.entrypoint
// Code size 13 (0xd)
.maxstack 8
IL_0000: nop
IL_0001: ldstr "Hello world"
IL_0006: call void ConsoleApplication1.Foo::Write(string)
IL_000b: nop
IL_000c: ret
} // end of method Program::Main
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.