Я искал ответ в Google, используя:
«Тип Microsoft.SqlServer.Management.Smo.Server определен в сборке, на которую нет ссылок».
Почему для использования объектов управления сервером Microsoft Sql (SMO) в DAL требуются ссылки на библиотеки DLL SMO в проекте, на который ссылаются?
использование sql smo в упомянутых проектах
SQL SMO в многоуровневых решениях
Требования к справочнику по sql smo
и, вероятно, несколько других, и не нашли решения или объяснения этой проблемы.
По общему признанию, я всего лишь начинающий гуглер, поэтому, если кто-то захочет повысить мой уровень и указать путь к существующему ресурсу, я с удовольствием отправлюсь туда.
Вот мои настройки:
У меня многоуровневое решение: DAL, Business Logic, Services, UI. Есть проект hosts, в котором размещаются сервисы. На самом деле я использую расширение 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 (а-ля 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 на уровне сервисов не вызывает жалоб. Мой вопрос, почему? Более конкретно: Зачем BLL нужны ссылки на SMO, когда класс Utilities в DAL уже абстрагируется от типов SMO?
Я хочу, чтобы вся база данных, связанная с базой данных, жила в DAL (дух) и только бизнес-логика в BLL (двойной дух). Есть ли другой способ добиться этого с помощью SMO, который я упустил из виду?
Спасибо за ваше ценное время и ответы, я смиренно жду ваших ответов
Изменить: я скорректировал свое решение на основе предложений Криса, проверил, что я использую ссылки на проект (я), прочитал ссылки на SMO в DAL, используя Muse.VSExtensions, чтобы добавить ссылку GAC, прежде чем я просматривал и добавляя вручную, затем я пошел дальше и установил Copy Local = True для этих сборок, чтобы быть вдвойне уверенным, что они рядом... но я все еще застрял с этой раздражающей ошибкой компиляции.
