Причина принятия решения о проектировании (то, что сборка не может видеть многословие) заключается в следующем:
(1) Процесс сборки не должен предполагать, что хочет пользователь (и выбранные им регистраторы).Они не обязательно принадлежат одному и тому же человеку.Подумайте о том, чтобы подойти к сборке, в которой задача знает многословие и регистрирует только определенную информацию при диагностическом многословии.Вы хотите построить на консоли тихую многословность, а также подключить регистратор базы данных, который регистрирует абсолютно все.Вы не можете этого сделать, потому что задача никогда не запускала событие, потому что она видит тихое многословие.
(2) Важность и многословие запутаются.Важность - это подсказка процесса сборки относительно того, что регистраторы с определенной многословностью могут захотеть сделать с событием.Они существуют в отдельных сферах: важность в задачах и процессе сборки, многословность только в регистраторах.
(3) Сама многословность (например, / verbosity) является просто значением по умолчанию.Регистраторы, как правило, позволяют вам указать конкретное многословие для них.Например / fileloggerparameters: verbosity = подробный.Что должно получить задание?Их может быть несколько.
Сказав, что в ретроспективе есть одна веская причина пересмотреть это.Это связано с тем, что запуск большого количества событий в объекте Log, что вы могли бы разумно сделать для диагностики, может значительно повлиять на производительность сборки даже при более низких подробностях, когда они удаляются регистратором.Чтобы исправить это, мы, вероятно, должны позволить процессу сборки, по крайней мере, знать, находится ли он в каком-то «супер-многословном» режиме, в котором безопасно вести себя как сумасшедший.
Кроме того, в конечном итоге важно то, как выполнить свою работу.Так что, возможно, все эти тонкости были слишком сложными вещами.
Дэн - много лет назад я помогал спроектировать это.