Джошуа отчасти прав ... Для потомков я хотел бы добавить немного больше к этому ответу, поскольку я несколько раз сталкивался с одними и теми же проблемами. Во-первых, нужно рассмотреть их архитектуру. Существует несколько проблем, с которыми вы можете столкнуться с файлами .config в ASP.NET в зависимости от развертывания.
Учитывая архитектурные разветвления:
Один уровень (один сервер): простое веб-приложение может использовать ссылку на файл Web.config сайтов и решать ваши проблемы. Это было бы прекрасным решением для одноуровневого приложения. В случае приложения Windows, используемого в виде файла .exe, App.config также будет работать.
Я надеюсь, что эти пункты сэкономят вам время и сэкономят головную боль. Я знаю, что потерял пару дней программирования, решая эти проблемы... и было трудно найти все причины в одном месте, почему приложение не "реализовало" свой объект подключения. Надеюсь, это спасет вас всех от той же участи, что и я.
Многоуровневость (более одного сервера). Вот тут-то мне и стало немного не по себе, когда я впервые работал с файлами .config за пределами границ. Помните об иерархии структуры конфигурации и помните об этом (Статья MSDN о структуре .Config) — в корневом каталоге соответствующей папки ASP.NET находится файл machine.config. Они находятся на каждом физическом сервере. Они переопределяются сайтом Web.config (или App.config), который, в свою очередь, переопределяется файлами .config вложенных папок. Если у вас есть более одного файла .config, вы можете использовать один из методов для передачи пути к файлу для конкретного .config, который вы хотите использовать. Что еще более важно, каждый из этих файлов может содержать информацию о соединении. Machine.config ASP.NET содержит некоторые данные для фреймворка... так что вы должны, по крайней мере, учитывать тот факт, что это цепочка "наследования". Во-вторых, любые изменения в файле Web.config после развертывания потребуют перезапуска приложения. Это приведет к потере состояния (плохо, если у вас есть активные пользователи на сайте). Обойти это можно, сохранив отдельный файл .config (например, connection.config) и поместив ссылку на этот файл в файл Web.config. Это позволит вам изменить информацию о подключении (например, пароль) без перезапуска приложения. Вот ссылка на дополнительную информацию: MSDN: работает с файлами конфигурации. В этой статье изложены все детали, о которых вам необходимо знать в обычном приложении, развернутом на сервере или в IIS. Имейте в виду, что файлы .config в основном предназначены для приложений, а не для библиотек. Если у вас несколько уровней, скорее всего, вы используете какой-то уровень связи/обмена сообщениями (например, WCF). Это будет иметь/разрешить собственный Web.config. Вы можете хранить там строки подключения (и шифровать их при необходимости), но еще лучше поместить их во второй файл, на который ссылается Web.config, для удобства управления. И последний момент: если вы когда-либо собираетесь рассматривать облако, файлы .config завернуты для развертывания приложений, что фактически лишает их всех преимуществ, которые они предлагают с точки зрения «отсутствия перезапуска или повторного развертывания». Развертывания Azure захотят рассмотреть эту статью, чтобы избавить себя от кошмаров обслуживания: Блог Билла Лодина — Файлы конфигурации в Azul / Cloud. Еще один момент в этой статье — отличный пример того, как программно выбрать конфигурацию в зависимости от развертывания! Обязательно ознакомьтесь с этим, если вы хотите повысить гибкость развертывания в облаке или за его пределами.
person
Zack Jannsen
schedule
16.11.2012
