Результаты поиска

Итак, я не хочу начинать здесь священную войну, но мы находимся в процессе консолидации того, как мы обрабатываем файлы конфигурации наших приложений, и мы изо всех сил пытаемся принять решение о наилучшем подходе. На данный момент каждое приложение, которое мы распространяем, использует свои собственные специальные конфигурационные файлы, будь то файлы свойств (ini style), XML или JSON (внутреннее использование только в данный момент!).

Большая часть нашего кода на данный момент является Java, поэтому мы смотрели на Apache Commons Config , но мы обнаружили, что он довольно многословен. Мы также посмотрели на XMLBeans,но похоже, что это очень много обмана. Я также чувствую, что меня подталкивают к формату XML, но мои клиенты и коллеги опасаются попробовать что-то другое. Я могу понять это с точки зрения клиента, все слышали о XML, но в конце концов, не следует ли использовать правильный инструмент для работы?

Какие форматы и библиотеки люди используют в производственных системах в наши дни, пытается ли кто-нибудь еще избежать налога на угловые скобки ?

Edit: действительно должно быть кроссплатформенное решение: Linux, Windows, Solaris и т. д. и выбор библиотеки, используемой для взаимодействия с конфигурационными файлами, так же важен, как и выбор формата.

Кто-нибудь придумал, как заставить PowerShell использовать app.config файлов? У меня есть пара .NET DLL, которые я хотел бы использовать в одном из своих сценариев, но они ожидают, что их собственные разделы конфигурации будут присутствовать в app.config / web.config .

В проекте .NET предположим, что у вас есть параметр конфигурации, например строка подключения, хранящаяся в файле app.config, который отличается для каждого разработчика в вашей команде (они могут использовать локальный сервер SQL, или конкретный экземпляр сервера, или использовать удаленный сервер и т. д.).

Как вы можете структурировать свое решение так, чтобы каждый разработчик мог иметь свою собственную разработку "preferences" (т. е. не проверено в системе управления версиями), но предоставляет строку подключения по умолчанию, которая проверяется в системе управления версиями (тем самым предоставляя правильные значения по умолчанию для процесса сборки или новых разработчиков).

Кто-нибудь придумал, как заставить PowerShell использовать app.config файлов? У меня есть пара .NET DLL, которые я хотел бы использовать в одном из своих сценариев, но они ожидают, что их собственные разделы конфигурации будут присутствовать в app.config / web.config .

Не мог бы кто-нибудь сделать краткое описание того, как программно зашифровать конфигурационный файл в .NET, предпочтительно в C#.

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

Также если бы кто-нибудь мог перечислить типы шифровальщиков и в чем разница между ними.

Я не знаю, является ли код для выполнения этого в обычном WinForms-приложении прозрачным для выполнения этого в ASP.NET.