VB.NET WinForm代码移入DLL后无法访问Checkbox状态问题咨询

你的判断是对的。DLL作为独立类库程序集，默认和主EXE的依赖方向是主EXE引用DLL，如果反过来让DLL引用主EXE会造成循环依赖，属于设计硬伤。你代码里写的Form1.CheckBox102是VB.NET主程序集内特有的默认窗体实例作用域，DLL既没有主程序的窗体类型定义，也访问不到主程序运行时生成的窗体实例，自然会失效。

1. 最优方案：仅传入业务需要的状态值，不传递控件/窗体引用 #

你的敏感逻辑本质上只需要CheckBox的Checked布尔状态，根本不需要操作控件本身。直接把DLL内方法的参数定义为需要的基础类型值，主程序调用时把对应控件状态传入即可，完全不需要让DLL感知任何UI层的存在。
示例：
DLL内的敏感逻辑代码：

Public Class SensitiveCore
    ''' <summary>
    ''' 执行敏感业务逻辑
    ''' </summary>
    ''' <param name="isCheck102Checked">对应原CheckBox102的选中状态</param>
    Public Sub ExecuteSensitiveRule(isCheck102Checked As Boolean)
        If isCheck102Checked = False Then
            ' 原有敏感逻辑
        End If
    End Sub
End Class

主程序调用代码：

Dim core As New SensitiveCore()
' 仅传入需要的状态值，不暴露控件本身
core.ExecuteSensitiveRule(Form1.CheckBox102.Checked)

这个方案的优势：

• 完全符合封装原则，DLL和UI层彻底解耦，后续哪怕你把项目换成WPF、控制台程序，这段敏感逻辑都能直接复用
• 不会出现控件误操作问题，DLL拿不到控件实例，不可能随意修改UI属性、触发控件事件造成主程序异常
• 没有任何循环依赖问题，依赖方向完全合理
• 如果需要传递的状态多，可以在DLL内定义一个纯属性的状态传输类，把所有需要的布尔值、业务值打包传递，维护成本很低：

  Public Class UiStateDto
      Public Property Check102Checked As Boolean
      Public Property Check103Checked As Boolean
      ' 按需添加其他需要的状态属性
  End Class
  

2. 次选方案：传入对应控件实例 #

如果确实有需要直接操作控件的场景，可以给DLL项目添加框架自带的System.Windows.Forms程序集引用，直接让方法接收对应类型的控件参数即可，不需要反向引用主EXE。
示例：
DLL内代码（需先添加System.Windows.Forms引用）：

Imports System.Windows.Forms

Public Class SensitiveCore
    Public Sub ExecuteSensitiveRule(check102 As CheckBox)
        If check102.Checked = False Then
            ' 敏感逻辑
        End If
    End Sub
End Class

主程序调用时直接传入控件实例：

Dim core As New SensitiveCore()
core.ExecuteSensitiveRule(Form1.CheckBox102)

注意：这个方案会让你的DLL强绑定WinForm技术栈，且DLL可以随意修改传入控件的所有属性，容易引入不可控的UI异常，非必要不使用。

3. 不推荐方案：建立全局关联链路 #

你提到的建立DLL和主窗体关联链路的方式是可行的，比如在DLL内定义静态全局属性，主程序启动时把窗体实例赋值给该属性，供DLL全局访问。但这个方案存在强耦合、内存泄漏风险高、维护成本极高的问题，只要主程序改了控件名、调整了窗体结构，DLL就会直接运行报错，完全不符合封装要求，非常不建议使用。

绝对不要为了让DLL访问Form1，给DLL项目添加对主EXE项目的引用，这会直接造成双向循环依赖，编译报错且后期完全无法维护。

内容的提问来源于stack exchange，提问作者user1500403