是否可以在程序集级别启用Visual Studio中的循环依赖项？相互依赖的组件是否可能？
Dan*_*Tao 15 .net c# vb.net circular-dependency visual-studio
这听起来像是一个愚蠢的问题,但无论如何我都会试一试.
因此在Visual Studio中,您不能有两个项目X和Y,以便X引用Y和Y引用X.
总的来说,由于各种原因,我完全可以理解循环依赖是如何产生问题的.
但是,以这种方式编译两个相互依赖的项目真的不可能吗？在我看来,它必须是可能的,因为(在我的脑海-也许我完全关闭基地这个)有两个互相依赖的组件真的不是那么由具有两个相互依存类不同-它的情况是合法的,可以编译.
如果你说,"两个程序集不能相互依赖,因为编译器无法在另一个程序集之前编译",这对我来说是有意义的; 除了看起来你可以为同一个程序集中的两个类创建相同的参数,显然编译器可以很好地处理这个场景.
基本上我问的原因并不是我有一些绝望的愿望去做这件事,我知道这通常是不明智的.具体来说,我想知道,因为如果我可以有两个项目 - 比如MyProjectCS和MyProjectVB - 基本上作为单个单元的两个相互依赖的部分存在,并且只是分开因为某些部分是用C#编写的,这将是很好的.其他部分都是用VB.NET编写的.
所以,我的问题是(yikes,three-fold):
- 是否可以启用此行为(在Visual Studio中或其他地方)？
- 如果在任何IDE中都不可能,至少在理论上是否可行,或者可能存在相互依赖的程序集？
- 如果它在理论上甚至不可能,为什么不呢？换句话说,相互依赖的程序集与单个程序集中的相互依赖的代码有何不同？
Jos*_*hua 12
我不知道如何在IDE中执行此操作; 然而,可以通过compilicated构建过程来构建.
你会需要:
- 大会A.
- 大会B.
- Stub Assembly B
其中Stub程序集B包含程序集B的公共类和公共方法以及相同的AssemblyInfo.*并引用相同的公钥.
构建顺序:
- 编译存根组件B.
- 将Stub Assembly B复制到Assembly B的输出目录
- 构建程序集A.
- 构建程序集B.
请注意,您不能在方法签名中对类型进行直接循环引用; 但是你可以通过对象进行强制循环.
注意:
ilasm可以编译真正的相互递归程序集,因为它可以解析在编译时不存在的类型.
进一步:
aspnet_compiler似乎能够在同一个项目中混合使用不同的语言(谁知道如何).
- 您可以使用更复杂的构建过程在方法签名的类型中使用循环:首先定义所有类并对其进行编译,然后设置继承层次结构(使用上一步中的存根)并添加所有非重写方法(但没有实体),并在第三遍最后做一个正常的编译(现在最终包括方法体).如果你真的想这样做,#if将是你最好的朋友. (3认同)
即使mscorlib.dll和System.dll程序集是相互依赖的,我建议永远不要让2个程序集相互依赖.
关于名称空间之类的hings之间的依赖循环,我建议使用NDepend来检测和避免依赖循环.
摘自文章(我写的):控制组件依赖关系以获得干净的架构
组件之间的依赖循环导致通常称为意大利面条代码或纠结代码.如果组分A取决于取决于取决于A的C的B,则组分A不能独立于B和C进行开发和测试.A,B和C形成不可分割的单元,一种超级组分.由于规模现象的不经济性,这种超级组件的成本高于A,B和C的成本之和(在软件估算中有详细记载:Steve McConnell揭开黑暗艺术的神秘面纱).基本上,这表明开发不可分割的代码片段的成本呈指数级增长.
这表明,开发和维护1000 LOC(行代码)将有可能成本比开发和维护500 LOC,除非它能在每500 LOC的两个独立块被分割多三点四倍.因此,与意大利面条的比较描述了无法维持的纠结代码.以理顺架构,必须确保有组件之间没有依赖循环,而且还检查每个部件的尺寸是可接受的(500至1000 LOC).
- 一个非常周到和信息丰富的回应.但是,我只想指出,我主要是从想要能够在C#和VB.NET的组合中编写组件的角度来问这个问题.因此,尽管我得到了"超级组件"的含义,但我觉得它与我追求的完全不符.对我来说,"超级组件"将是多个相互依赖的组件的组合; 另一方面,我将称之为"混合组件",将***组件分解为(通过语言)为相互依赖的*部分*.那有意义吗？ (2认同)