Как Вы управляете.NET app.config файлы для крупных приложений?
В Java все находится в форме класса.
Если вы хотите использовать любой объект, тогда у вас есть две фазы:
- Объявить
- Инициализация
Пример:
- Объявление:
Object a; - Инициализация:
a=new Object();
То же самое для концепции массива
- Объявление:
Item i[]=new Item[5]; - Инициализация:
i[0]=new Item();
Если вы не дают секцию инициализации, тогда возникает NullpointerException.
5 ответов
Вы используете один основной файл конфигурации, который указывает на другие файлы конфигурации. Вот пример того, как сделать это.
<час>В случае, если ссылка гниет, что Вы делаете, указывают configSource для конкретного раздела конфигурации. Это позволяет Вам определять тот конкретный раздел в отдельном файле.
<pages configSource="pages.config"/>
, который подразумевает, что существует файл, названный "pages.config" в рамках того же каталога, который содержит все <pages /> дерево узла.
Мой предпочтительный метод состоит в том, чтобы использовать MSBuild, если Вы щелкнете правой кнопкой по проекту, и щелчок 'разгружаются', то новый пункт меню откроется, который говорит 'редактирование'. Выберите это, и это откроет файл проекта, таким образом, можно будет отредактировать его, прокрутить вниз, пока Вы не находите прокомментированный разделом, который называют "AfterBuild".
можно затем добавить что-то как:
<Target Name="AfterBuild">
<Delete Files="$(TargetDir)$(TargetFileName).config" />
<Copy SourceFiles="$(ProjectDir)$(Configuration).config" DestinationFiles="$(TargetDir)$(TargetFileName).config" />
</Target>
Это заменит конфигурацию приложения одним именованным [Release|Debug]app.exe.config. Таким образом, можно поддержать отдельные конфигурации в зависимости от того, как проект разрабатывается.
, Но быстрая и грязная опция (если Вы не хотите играть с msbuild) должен просто поддержать отдельные файлы конфигурации и затем определить, какой Вы хотите включать, как это:
<appSettings configSource="Config\appSettingsDebug.config"/>
<roleManager configSource="Config\roleManagerDebug.config"/>
И если Вы делаете приложение asp.net, Microsoft обеспечивает большую утилиту, названную "веб-Проекты Развертывания", которые позволят Вам справляться, все это легко, щелкает здесь
Отличный способ управлять большими наборами конфигурации состоит в том, чтобы создать разделы пользовательской конфигурации. Phil Haack обсуждает это очень приятно в этой Пользовательской конфигурации статьи разделы на 3 легких шагах
Настройте конфигурации сборки для каждого Вашего развертывания/тестовой среды и используйте отдельные файлы конфигурации на основе каждой конфигурации сборки.
ScottGu имеет хорошее сообщение об этом, и он работает отлично. Единственная причуда, которую мы имеем, - то, что мы должны удостовериться, что файлы конфигурации (web.config) проверяются для редактирования от TFS перед каждой сборкой так, чтобы это могло быть скопировано.
Мы создали класс AssemblySettingsConfig, который действует как ConfigurationManager, но загружает .config для каждого отдельного блока. Таким образом, приложение имеет .config, и любые DLLs, на которые оно ссылается, имеют свои собственные .config файлы. Удался хорошо до сих пор.