When creating a custom Task how to get access to the MSBuild verbosity?

In the context of creating a custom Microsoft.Build.Utilities.Task how do I get access to the MSBuild verbosity?

Microsoft.Build.Utilities.Task: http://msdn.microsoft.com/en-us/library/microsoft.build.utilities.task.aspx

MSBuild verbosity: Link

I don't think it works that way. You get a reference to the build engine through Task.BuildEngine property. Then simply call its LogMessageEvent to generate a message. The BuildMessageEventArgs.Importance determines whether or not the message will actually be visible, based on the verbosity setting. This is consistent with other logging APIs.

The reasoning behind the design decision (that the build cannot see the verbosity) is the following:

(1) The build process should not assume what the user (and the loggers she chooses) want. They are not necessarily owned by the same person. Consider walking up to a build where a task knows about verbosity and only logs certain information at diagnostic verbosity. You want to build at quiet verbosity on the console but also attach a database logger that logs absolutely everything. You can't because the task never fired the event because it sees the quiet verbosity.

(2) Importance and Verbosity would get confused. Importance is the build process's hint as to what loggers, with a particular verbosity, might want to do with the event. They exist in separate realms: Importance in the tasks and build process, Verbosity only in loggers.

(3) Verbosity itself (eg., /verbosity) is just a default value. Loggers typically allow you to specify a specific verbosity for them. For example /fileloggerparameters:verbosity=detailed. Which should the task get? There might be several.

Having said that, in retrospect there is one good reason to reexamine this. That is because firing a lot of events on the Log object, which you might reasonably do for diagnostics, can significantly affect the build performance even at lower verbosities where they're getting discarded by the logger. To fix this we should probably allow the build process to at least know whether it's in some kind of "super verbose" mode where it's safe to log like crazy.

Also, what ultimately matters is Getting Your Job Done. So perhaps all these niceties were overcomplexifying things.

Dan -- years back I helped design this.