0

我使用以下方法在谷歌上搜索了答案：

“'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 中的类已经抽象出 SMO 类型时，为什么 BLL 需要对 SMO 的引用？Utilities

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

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

编辑：我已经根据 Chris 的建议调整了我的解决方案，验证了我正在使用项目 refs（我是），在我浏览和手动添加，然后我继续为这些程序集设置 Copy Local = True 只是为了确保它们在附近......但我仍然遇到这个烦人的编译错误。

4

2 回答 2

1

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

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

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

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

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

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

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

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

于 2012-01-25T22:01:15.600 回答
0

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

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

于 2012-01-30T02:07:29.523 回答