Почему использование объектов управления сервером Microsoft Sql (SMO) в DAL требует ссылки на библиотеки SMO ​​в проекте, который ссылается на DAL? - PullRequest
0 голосов
/ 26 января 2012

Я искал ответ в Google, используя:

"Тип" Microsoft.SqlServer.Management.Smo.Server "определен в сборке, на которую нет ссылок."

Почему для использования Microsoft Sql Server Management Objects (SMO) в DAL требуются ссылки на библиотеки SMO ​​в ссылочном проекте?

с использованием sql smo в ссылочных проектах

sqlsmo в многоуровневых решениях

sql ссылочные требования smo

и, возможно, несколько других, которые не нашли решения или объяснения этой проблемы.

Правда, я всего лишьподмастерье, гуглер, так что если кто-то захочет повысить уровень меня и указать путь к существующему ресурсу, я с радостью пойду отсюда.

Вот мои настройки:

У меня есть многоуровневое решение: DAL, Business Logic, Services, 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 (в целом), как и ожидалось.Когда я компилирую, я получаю:

Тип 'Microsoft.SqlServer.Management.Smo.Server' определяется в сборке, на которую нет ссылок.Необходимо добавить ссылку на сборку 'Microsoft.SqlServer.Smo, версия = 10.0.0.0, Culture = нейтральный, 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 на уровне служб не вызывает претензий.У меня вопрос, почему?Более конкретно: Зачем BLL нужны ссылки на SMO, когда класс Utilities в DAL уже абстрагирует типы SMO?

Что мне нужно, чтобы вся база данных имела отношение к жизни вDAL (Дух) и только бизнес-логика в BLL (двойной Дух). Есть ли другой способ добиться этого с помощью SMO, который я упустил из виду?

Спасибо за ваше драгоценное время и ответы, я смиренно жду ваших ответов

Редактировать: я скорректировал свое решение на основе предложений Криса, проверил, что я использую ссылки на проекты (я), перечитал ссылки на SMO в DAL, используя Muse.VSExtensions, чтобы добавить ссылку GAC, прежде чем я былпросматривая и добавляя вручную, я продолжил и установил Copy Local = True для этих сборок, просто чтобы быть вдвойне уверенным, что они рядом ... но я все еще застрял с этой досадной ошибкой компиляции.

Ответы [ 2 ]

1 голос
/ 26 января 2012

Я думаю, что это сводится к тому, как на вещи ссылаются в вашем решении.Итак, я собираюсь сделать пару предположений.

Похоже, ваша DLL ссылается на DAL как сборку, а не как ссылку на проект.

Во время компиляции Visual Studio копирует все, что считает необходимым, в каталог BIN проектов.Если вы ссылаетесь на внешнюю DLL (DAL), она скопирует эту DLL only в каталог BIN вашего BLL.

Что вам нужно сделать, так это заставить его скопировать сборки SMO ​​ИЛИ сделать эти сборки SMO ​​доступными через GAC.Лично мне не нравятся вещи GAC, поэтому я проигнорирую это.

Есть три способа сделать это.Самое простое - просто добавить ссылку на эти другие сборки в свой BLL.Очевидно, это не то, что вам нужно.

Второй способ - ссылаться на проект DAL как на ссылку project .Это позволит Visual Studio обнаруживать дополнительные зависимости и копировать их соответствующим образом.Это также не совсем то, что вам нужно.

Третий способ - скопировать их как часть шага сборки.Щелкните правой кнопкой мыши по вашему проекту BLL и перейдите к Build Events.В командной строке события Pre-build введите команды для копирования необходимых SMO-файлов в каталог BIN проектов BLL.

Вы должны будете сделать это снова и для основного проекта службы.

0 голосов
/ 30 января 2012

Уныло отвечать на твой собственный вопрос с виноватым меа: «Я идиот» ... но, ну, я идиот:

В Utilities произошла перегрузка для метода-нарушителя, который сделал , содержащий параметр Smo.Server. Я удалил эту перегрузку (артефакт из тестирования перед рефакторингом) и вуаля, проблема решена / идиотизм подтвержден! Интересно, что я узнал здесь, что использование других методов класса Utilities, у которых не было перегрузок, содержащих объекты Smo, было абсолютно нормальным, то есть даже с функцией в классе Utilities, которая требовала объект Smo для Параметр, пока я не не вызвал этот метод или одну из его перегрузок , ссылки решались без проблем. У меня новый вопрос, почему? Почему существование этой перегрузки имеет значение для разрешения ссылок, если я вызываю другую версию этой функции из проекта выше в цепочке зависимостей? Есть ли какой-то внутренний цикл, где он проходит по всем версиям функции, проверяя ссылки, если какая-либо версия была вызвана ...

...