为什么在 DAL 中使用 Microsoft Sql Server 管理对象 (SMO) 需要在引用 DAL 的项目中引用 SMO dll？

Question

我在谷歌上搜索了答案，使用：

“类型'Microsoft.SqlServer.Management.Smo.Server'是在未引用的程序集中定义的。”

为什么在 DAL 中使用 Microsoft Sql Server 管理对象 (SMO) 需要引用引用项目中的 SMO dll？

在引用的项目中使用 sql smo

在分层解决方案中使用 sql smo

sql smo 参考要求

以及可能的其他一些要求，但尚未找到此问题的解决方案或解释。

诚然，我只是一个熟练的谷歌搜索者，所以如果有人希望给我力量并指出现有资源的方向，我会很乐意从那里开始探索。

这是我的设置：

我有一个分层解决方案：DAL、业务逻辑、服务、UI。有一个托管服务的主机项目。我实际上使用 VS2010 扩展 layerguidance.codeplex.com 来设置所有这些项目，这非常好。我使用的是 SQL Server 2008 Express 和 SMO v 10。所有解决方案项目均使用项目引用进行引用。所有项目都编译到一个公共的顶级 Bin 文件夹中。

现在的问题是：

在 DAL 中的类中，我有一个 SmoTasks 类，它处理与 SMO 对象的接口，还有一个 Utilities 类，它从 < code>SmoTasks 并提供对其功能的访问，而不需要任何 SMO 对象作为参数，以便引用项目（读取：业务逻辑层）可以使用非 SMO 类型进行接口。 DAL 中的一切都很好，编译得很好，方法通过了测试 - 它在我的世界中的地位感觉很好。然后，在 BLL 中，我有一个组件，它使用 Utilities 类来处理将通过服务公开的应用程序的数据库配置。 BLL 使用对 DAL 的项目引用，并按预期查看 DAL 类（按照智能感知）。当我编译时，我得到：

类型“Microsoft.SqlServer.Management.Smo.Server”是在未引用的程序集中定义的。您必须添加对程序集“Microsoft.SqlServer.Smo, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91”的引用。

BLL 中的代码如下所示：

 public bool CreateTables(string connectionString)
    {

        bool result = default(bool);


        // Data access component declarations.
        Utilities utilities = new Utilities();

        // Step 1 - Calling CreateTables on Utilities.
        result = utilities.CreateTables(connectionString);

        return result;

    }

错误指向的行是：

result = utilities.CreateTables(connectionString);

I显然，可以将 SMO 引用添加到 BLL，然后 BLL 会很高兴，但这违反了我松散耦合项目的设计目标。如果我将 SMO 程序集添加到 BLL，它会进行编译，然后在服务层中引用 BLL 对象不会引起投诉。我的问题是，为什么？更具体地说：当 DAL 中的 Utilities 类已经抽象出 SMO 类型时，为什么 BLL 需要引用 SMO？

我想要的是与存在于数据库中的所有数据库相关的内容。 DAL（废话）和 BLL 中只有业务逻辑（双废话）。 是否有另一种方法可以使用我忽略的 SMO 来实现此目的？

感谢您的宝贵时间和回答，我谦虚地等待您的回复

编辑： 我根据 Chris 的建议调整了我的解决方案，验证了我正在使用项目引用（我是），在我手动浏览和添加之前，使用 Muse.VSExtensions 在 DAL 中读取了对 SMO 的引用以添加 GAC 引用，然后我继续为这些程序集设置 Copy Local = True，只是为了双重确保它们存在......但我仍然遇到这个恼人的编译错误。

Answer 1

我认为这可以归结为解决方案中如何引用事物。所以我要进行一些猜测。

听起来您的 DLL 将 DAL 作为程序集引用，而不是作为项目引用。

在编译时，Visual Studio 会将其认为必需的所有内容复制到项目 BIN 目录中。如果您引用外部 DLL (DAL)，那么它只会将该 DLL 复制到 BLL 的 BIN 目录。

您需要做的是让它复制 SMO 程序集，或者通过 GAC 提供这些 SMO 程序集。就我个人而言，我不喜欢 GAC 处理的事情，所以我会忽略它。

有三种方法可以做到这一点。最简单的方法是简单地将对这些其他程序集的引用添加到 BLL 中。显然这不是你想要的。

第二种方法是将 DAL 项目作为项目引用进行引用。这将允许 Visual Studio 检测额外的依赖项并相应地复制它们。这也不完全是您想要的。

第三种方法是将它们作为构建步骤的一部分进行复制。右键单击您的 BLL 项目并转到“构建事件”。在预构建事件命令行中输入命令，将必要的 SMO 文件复制到 BLL 项目 BIN 目录。

您还必须对主要服务项目再次执行此操作。

Answer 2

带着歉意回答自己的问题是令人沮丧的，“我是个白痴”……但是，好吧，我是个白痴：

在Utilities中，有问题的方法有一个重载， 是否包含Smo.Server参数。我删除了该过载（重构前测试中的一个工件），瞧，问题解决了/白痴得到了证实！我在这里学到的有趣的事情是，使用 Utilities 类的其他方法（没有包含 Smo 对象的重载）绝对没问题，这意味着即使使用 Utilities 中的函数也是如此。 code> 类需要一个 Smo 对象作为参数，只要我没有调用该方法或其重载之一，引用就会完美地解析。我的新问题是，为什么？如果我从依赖链较高的项目中调用该函数的另一个版本，为什么该重载的存在对于引用解析很重要？是否存在一些内部循环，它会遍历函数的所有版本，检查引用是否已调用任何版本...