Блог

Я работаю с большим решением, состоящим в основном из проектов, ориентированных на .NET Framework 4.x. В ряде проектов в решении используются файлы Settings.settings. При добавлении новых параметров или изменении значений с помощью редактора Visual Studio по умолчанию для файлов .settings изменения отражаются в файле app.config для соответствующего проекта.

Разделы конфигурации, автоматически сгенерированные на этом этапе, форматируются с несколькими атрибутами на строку, вплоть до некоторого ограничения длины строки, после чего атрибуты переносятся в новую строку. Например, мы могли бы увидеть что-то вроде:

 <setting name="SomeBackgroundTaskIntervalSeconds" serializeAs="String">
    <value>60</value>
</setting>
 

Однако в то же время у нас также есть настройки в инструментах Visual Studio -> Параметры ->> Текстовый редактор ->>> XML ->>>> Форматирование. У нас есть опция «Атрибуты», настроенная на «Выравнивание атрибутов в отдельной строке», как мы предпочитаем форматирование XML как команда разработчиков, и мы делимся файлом .vssettings с командой и новыми разработчиками, чтобы убедиться, что мы все на одной странице. Это означает, что если кто-то вносит изменения в файл .config и выполняет «Форматирование документа», вышеупомянутый раздел конфигурации обновляется до:

 <setting name="SomeBackgroundTaskIntervalSeconds"
         serializeAs="String">
    <value>60</value>
</setting>
 

Эти параметры полностью игнорируются Visual Studio при создании разделов конфигурации из файлов settings.settings. В результате этого мы довольно часто сталкиваемся с различиями Git, в которых есть сотни «изменений» строк, которые являются просто новой строкой, измененной на пробел, или наоборот. Это, конечно, полная боль, особенно при попытке разрешить конфликты слияния в таких файлах.

Кто-нибудь знает, есть ли способ заставить Visual Studio создавать разделы конфигурации, которые учитывают собственные настройки Visual Studio в отношении форматирования XML?

Мы могли бы изменить параметры форматирования XML, упомянутые выше, по всей команде, но, по-видимому, было бы стыдно прибегать к этому, чтобы избежать того, что кажется несоответствием VS.