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

【问题标题】：Why does using Microsoft Sql Server Management Objects (SMO) in the DAL require references to SMO dlls in a project which references the DAL?为什么在 DAL 中使用 Microsoft Sql Server 管理对象 (SMO) 需要在引用 DAL 的项目中引用 SMO dll？
【发布时间】：2012-02-19 02:40:48
【问题描述】：

我在谷歌上搜索了答案：

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

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

在引用的项目中使用 sql smo

分层解决方案中的sql smo

sql smo参考要求

可能还有其他一些人尚未找到此问题的解决方案或解释。

诚然，我只是一个熟练的 googler，所以如果有人想给我升级并指出现有资源的路径，我很乐意从那里开始探索。

这是我的设置：

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

现在的问题：

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

“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);

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

我想要的是所有与 DAL 相关的数据库（duh），并且只有 BLL 中的业务逻辑（double duh）。 是否有其他方法可以使用我忽略的 SMO 来实现？

感谢您宝贵的时间和回答，我恭候您的回复

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

【问题讨论】：

奇怪的是，将有问题的行注释掉，允许编译。在 Utilities 中还有其他看起来与此相同的函数，只是它们调用了不同的方法。 Utilities 方法看起来都差不多，只是传递给 SmoTasks...

标签： c# visual-studio-2010 sql-server-2008 smo assembly-references

【解决方案1】：

我认为这归结为您的解决方案中如何引用事物。所以我要猜几个。

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

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

您需要做的是让它也复制 SMO 程序集，或者让这些 SMO 程序集通过 GAC 可用。就个人而言，我不喜欢 GAC 的东西，所以我会忽略它。

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

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

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

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

【讨论】：

从技术上讲，还有第四种方法。手动将 SMO 程序集复制到 BAL 的 BIN 目录。但是，这些文件完全有可能会被删除，而您又会回到开始的地方。
在这种情况下，我使用所有项目引用来引用 BLL、DAL、服务层等。也许你可以解释为什么这不是我想要的（我欢迎更多的理解），但假设是，引用应该有效，对吧？
该死，我以为你让我朝着正确的方向前进，因为如果程序集引用设置为 true，我检查了“复制本地”属性，奇怪的是它不是（就像GAC，除了这些是通过浏览到他们的文件夹添加的，因为它们没有出现在 GAC 列表中）。我更改了它，程序集出现在 bin 文件夹中，但错误仍然存在。我查看了 BLL 的 obj/ResolveAssemblyCache.cache 并在其中看到了 smo 程序集及其路径，但是，同样的编译错误。

【解决方案2】：

用一个过失来回答你自己的问题令人沮丧，“我是个白痴”......但是，好吧，我是个白痴：

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

【讨论】：