Build. Utilities Namespace
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.
Contains information about entries in the AssemblyFoldersEx registry keys.
Represents information about assembly folders.
This class is the filetracking log interpreter for .read. tracking logs in canonical form or those that have been rooted (^) to make them canonical
This class is the filetracking log interpreter for .write. tracking logs in canonical form Canonical .write. logs need to be rooted, since the outputs need to be associated with an input.
(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.
This class contains utility functions to encapsulate launching and logging for the Tracker
Class used to store and interrogate inputs and outputs recorded by tracking operations.
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.
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.
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.
Processor architecture utilities
Structure to represent the information contained in SDKManifest.xml
Helper class with attributes of SDKManifest.xml
Structure to represent a target platform sdk
This helper base class provides default functionality for tasks. This class can only be instantiated in a derived form.
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.
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 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.
Base class used for tasks that spawn an executable. This class implements the ToolPath property which can be used to override the default path.
This class contains utility functions to assist with tracking dependencies
Used to specify the targeted bitness of the .NET Framework for some methods of ToolLocationHelper
Enumeration to express the type of executable being wrapped by Tracker.exe
The return value from InitializeHostObject. This enumeration defines what action the ToolTask should take next, after we've tried to initialize the host object.
What should happen if multiple versions of a given productfamily or sdk name are found
Type of SDK
Used to specify the targeted version of the .NET Framework for some methods of ToolLocationHelper.
The possible types of up to date check that we can support
Used to specify the version of Visual Studio from which to select associated tools for some methods of ToolLocationHelper
Dependency filter delegate. Used during TLog saves in order for tasks to selectively remove dependencies from the written graph.