Microsoft.Build.Utilities Namespace

Provides helper classes that you can use to create your own MSBuild loggers and tasks. For information, see MSBuild.

Classes

AppDomainIsolatedTask	This class provides the same functionality as the Task class, but derives from MarshalByRefObject so that it can be instantiated in its own app domain.
AssemblyFoldersExInfo	Contains information about entries in the AssemblyFoldersEx registry keys.
AssemblyFoldersFromConfigInfo	Represents information about assembly folders.
CommandLineBuilder	(1) Make sure values containing hyphens are quoted (RC at least requires this) (2) Escape any embedded quotes. -- Literal double quotes should be written in the form " not "" -- Backslashes falling just before doublequotes must be doubled. -- Literal double quotes can only occur in pairs (you cannot pass a single literal double quote) -- Functional double quotes (for example to handle spaces) are best put around both name and value in switches like /Dname=value.
LockCheck	This class implements checking what processes are locking a file on Windows. It uses the Restart Manager API to do this. Other platforms are skipped. Use the method GetLockedFileMessage(String) to get a message to inform the user which processes have a lock on a given file.
Logger	This helper base class provides default functionality for loggers that handle events raised by the build engine. This class can only be instantiated in a derived form.
MuxLogger	This is a multiplexing logger. The purpose of this logger is to allow the registration and deregistration of multiple loggers during the build. This is to support the VS IDE scenario where loggers are registered and unregistered for each project system's build request. This means one physical build may have multiple logical builds each with their own set of loggers. The Mux logger will register itself with the build manager as a regular central /l style logger. It will be responsible for receiving messages from the build manager and route them to the correct logger based on the logical build the message came from. Requirements: 1) Multiplexing logger will be registered at the beginning of the build manager's Begin build Any loggers registered before the build manager actually started building will get the build started event at the same time as the MUX logger Any loggers registered after the build manager starts the build will get a synthesised build started event. The event cannot be cached because the timestamp of the build started event is determined when the event is created, caching the event would give incorrect build times in the loggers registered to the MUX. 2) The MUX logger will be initialized by the build manager. The mux will listen to all events on the event source from the build manager and will route events correctly to the registered loggers. 3) The MUX logger will be shutdown when the build is finished in end build . At this time it will un-register any loggers attached to it. 4) The MUX logger will log the build finished event when the project finished event for the first project started event is seen for each logger. Registering Loggers: The multiplexing logger will function in the following way: A logger will be passed to the MUX Register logger method with a submission ID which will be used to route a the message to the correct logger. A new event source will be created so that the logger passed in can be registered to that event source If the build started event has already been logged the MUX logger will create a new BuildStartedEvent and send that to the event source. UnregisterLoggers: When a build submission is completed the UnregisterLoggers method will be called with the submission ID. At this point we will look up the success state of the project finished event for the submission ID and log a build finished event to the logger. The event source will be cleaned up. This may be interesting because the unregister will come from a thread other than what is doing the logging. This may create a Synchronization issue, if unregister is called while events are being logged.
ProcessorArchitecture	Processor architecture utilities
SDKManifest	Structure to represent the information contained in SDKManifest.xml
SDKManifest.Attributes	Helper class with attributes of SDKManifest.xml
TargetPlatformSDK	Structure to represent a target platform sdk
Task	This helper base class provides default functionality for tasks. This class can only be instantiated in a derived form.
TaskItem	This class represents a single item of the project, as it is passed into a task. TaskItems do not exactly correspond to item elements in project files, because then tasks would have access to data that wasn't explicitly passed into the task via the project file. It's not a security issue, but more just an issue with project file clarity and transparency. Note: This class has to be sealed. It has to be sealed because the engine instantiates it's own copy of this type and thus if someone were to extend it, they would not get the desired behavior from the engine.
TaskLoggingHelper	Helper logging class - contains all the logging methods used by tasks. A TaskLoggingHelper object is passed to every task by MSBuild. For tasks that derive from the Task class, it is provided in the Log property. This class is thread safe: tasks can log from any threads.
ToolLocationHelper	ToolLocationHelper provides utility methods for locating .NET Framework and .NET Framework SDK directories and files. NOTE: All public methods of this class are available to MSBuild projects for use in functions - they must be safe for use during project evaluation.
ToolTask	Base class used for tasks that spawn an executable. This class implements the ToolPath property which can be used to override the default path.
TrackedDependencies	This class contains utility functions to assist with tracking dependencies

Enums

DotNetFrameworkArchitecture	Used to specify the targeted bitness of the .NET Framework for some methods of ToolLocationHelper
HostObjectInitializationStatus	The return value from InitializeHostObject. This enumeration defines what action the ToolTask should take next, after we've tried to initialize the host object.
MultipleVersionSupport	What should happen if multiple versions of a given productfamily or sdk name are found
SDKType	Type of SDK
TargetDotNetFrameworkVersion	Used to specify the targeted version of the .NET Framework for some methods of ToolLocationHelper.
VisualStudioVersion	Used to specify the version of Visual Studio from which to select associated tools for some methods of ToolLocationHelper