В контексте создания пользовательского файла Microsoft.Build.Utilities.Task, как получить доступ к многословию MSBuild?При создании настраиваемой задачи, как получить доступ к многословию MSBuild?
Microsoft.Build.Utilities.Task: http://msdn.microsoft.com/en-us/library/microsoft.build.utilities.task.aspx
MSBuild подробность: http://blogs.msdn.com/b/saraford/archive/2008/10/07/did-you-know-you-can-configure-the-msbuild-verbosity-in-the-output-window-329.aspx
Я не думаю, что это работает таким образом. Вы получаете ссылку на механизм сборки через свойство Task.BuildEngine. Затем просто вызовите его LogMessageEvent для генерации сообщения. BuildMessageEventArgs.Importance определяет, действительно ли сообщение будет видимым, на основе параметра многословия. Это согласуется с другими API протоколирования.
Смысл проектного решения (что сборка не может видеть подробность) заключается в следующем:
(1) Процесс сборки не следует считать, что пользователь (и регистраторы она выбирает) хотят. Они не обязательно принадлежат одному и тому же человеку. Подумайте о том, чтобы подойти к сборке, где задача знает о многословии и только регистрирует определенную информацию в диагностической многословии. Вы хотите строить на тихой многословии на консоли, но также присоединяете регистратор базы данных, который регистрирует абсолютно все. Вы не можете, потому что задача никогда не запускала событие, потому что он видит тихую многословие.
(2) Важность и многословие будут запутаны. Важность - это подсказка процесса сборки относительно того, какие регистраторы, с определенной многословием, могут захотеть сделать с событием. Они существуют в отдельных сферах: Важность в задачах и процесс сборки, Верность только в регистраторах.
(3) Само многообразие (например,/verbosity) является значением по умолчанию. Обычно регистраторы позволяют указать для них определенную многословность. Например/fileloggerparameters: verbosity = detail. Какую задачу нужно выполнить? Их может быть несколько.
Сказав это, в ретроспективе есть одна веская причина пересмотреть это. Это связано с тем, что при запуске большого количества событий в объекте Log, которые вы могли бы разумно сделать для диагностики, может существенно повлиять на производительность сборки даже при более низких деталях, когда они отбрасываются регистратором. Чтобы исправить это, мы, вероятно, должны позволить процессу сборки, по крайней мере, знать, находится ли он в каком-то «сверхсовременном» режиме, где безопасно регистрироваться как сумасшедший.
Кроме того, что в конечном итоге имеет значение, это получение вашей работы. Поэтому, возможно, все эти тонкости были чрезмерно сложными.
Дэн - годы назад Я помог разработать это.