У меня проблема с компиляцией объектов базы данных в SubSonic 3.0 из-за проблем с расположением строки проекта и соединения

Question

У меня проблема с шаблонами T4 для генерации кода.

Мне интересно, может ли кто-нибудь помочь мне с моей проблемой. Я хочу сохранить строку подключения для использования с SubSonic 3.0 в расположении по умолчанию, например в корне веб-сайта (Web.Config или отдельный файл .config).

Это нормально, если шаблоны t4 «запускаются» в проекте, в котором есть файл конфигурации.

Я хочу отделить их от исходного проекта в отдельные файлы классов / проектов и запустить шаблоны оттуда.

Это все работает нормально, если я помещаю файл App.Config в эти проекты также со строкой соединения, но это не то, что я хочу, так как это затем жестко закодирует эти строки соединения в этих файлах классов. (Обратите внимание, что другие проекты файлов классов находятся в отдельном месте)

Лучший способ описать настройку (веб-приложение) следующим образом:

• Класс БД (Проект) | ---- Модели> Шаблоны T4 (ПРИМЕЧАНИЕ1) |
• Базовый класс (проект) |
• CMS класс (Проект) |
• Сайт (Проект) | ---- Web.Config <<< ConnectionString </li>

NOTE1: Шаблоны T4 в этом каталоге должны считываться из любого центрального файла в корневой папке веб-сайта (проекта). Поскольку сервер базы данных может измениться, это должно произойти.

Класс БД (Проект) находится совершенно в другом месте, чем Веб-сайт (Проект).

Это было достигнуто в dashCommerce, но с использованием SubSonic 2.0 (который, скорее всего, был компилятором командной строки, который сделал это, я не слишком уверен)

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

Класс БД будет уникальным для каждого проекта и будет скомпилирован на основе базы данных этого проекта с использованием шаблонов T4 в этой DLL. Другие DLL будут ссылаться на DLL класса DB, и они будут общими для проектов.

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

(Я понимаю, что могу просто создать и скомпилировать DLL-библиотеку БД для использования, НО при разработке / тестировании проект будет зависать на других DLLS, поскольку им тоже нужно ссылаться на строку подключения, ЕСЛИ я включаю ссылку на SubSonic, которая мне нужна чтобы получить доступ к объектам таблиц и т. д. из тех библиотек DLL, если я не создам весь код моста в классе DB, который будет просто сумасшедшим и бессмысленным для этого упражнения)

EDIT:

Я признаю, что это трудно объяснить. Я буду опираться на более простой пример. У меня есть два места: А.-Д .: \ Веб-приложение \ Core.DLL И B.- D: \ Веб-приложение \ Веб-сайт Я создаю новое решение C # .net «Веб-приложение» в папке «Веб-приложение» и добавляю к нему два проекта выше. (Обратите внимание, что это одно решение, содержащее два отдельных проекта в разных каталогах, которые могут находиться где угодно). Мне нужно, чтобы данные строки подключения были сохранены в проекте «Веб-сайт», и чтобы проект Core.DLL ссылался на них оттуда.

Core.Dll будет хранить tt-файлы и соответствующий код, сгенерированный для использования с SubSonic 3.0. Файлы tt будут «запускаться» из Visual Studio в проекте Core.Dll. Две проблемы:

• A.- Файлы tt не могут ссылаться на файл web.config (или могут ли они?) И
• B.- Код SubSonic по-прежнему должен уметь читать строку подключения во время выполнения. Можно ли с помощью App.config прочитать раздел строки подключения web.config? Или как бы я это сделал.

Answer 1

Спасибо, что ответили мне, Адам. Я только что понял это, когда ты написал, и решил, что я дам людям знать мой результат.

Только когда я покопался в сети о шаблонах Т4, мой разум начал действовать. Я ошибался, как работают шаблоны T4. Я думал, что файлы tt должны остаться с сгенерированными файлами кода.

Что я сделал, так это создал второй проект, просто для запуска шаблонов T4, который отделен от основного проекта. Я вставил строку подключения, которую я сейчас использую, и аналогично буду использовать только для разработки, а не для производства, так что я могу легко ее изменить. Это отлично работало и позволило мне скопировать сгенерированные файлы кода в проект класса DB DLL для использования.

То, что я не знал, как и многое из того, что вы сказали выше, было то, что когда проект работал полностью, он делал доступным файл Web.config для любых библиотек DLL и т.д., связанных с Веб-сайтом. Таким образом, это решило мою проблему со строкой подключения и тем, что ее легко было изменить в производственном процессе.

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

Теперь я могу получить доступ к своим объектам базы данных в любом месте проекта (включая любые библиотеки DLL, которые ссылаются на класс DLL БД) с помощью SubSonic.

Я должен сказать, что SubSonic определенно сделает мою жизнь проще. Одна строка кода для получения данных, теперь это хорошая мысль:)

Answer 2

ОК, я не уверен, что я на 100% согласен с тем, что вы здесь просите, но я сделаю все возможное

• A.- Файлы tt не могут ссылаться на файл web.config (или могут ли они?) И

Нет, но им действительно не нужно. Файл App.config для D: \ Web Application \ Core.DLL может содержать строку подключения. Если вас беспокоит дублирование строки подключения в web.config и app.config, вы можете добавить пользовательское событие сборки, которое копирует строку подключения из одной в другую.

• B.- Код SubSonic по-прежнему должен уметь читать строку подключения во время выполнения. Можно ли с помощью App.config прочитать раздел строки подключения web.config? Или как бы я это сделал.

Во время выполнения ваш сайт не будет ссылаться на app.config, как на web.config.