Multithreaded Task Migration

Note: [MSBuildMultiThreadableTask] has Inherited = false — it must be on each concrete class, not just the base.

Step 2: Absolutize Paths Before File Operations

All path strings must be absolutized with TaskEnvironment.GetAbsolutePath() before use in file system APIs. This resolves paths relative to the project directory, not the process working directory.

AbsolutePath absolutePath = TaskEnvironment.GetAbsolutePath(inputPath);
if (File.Exists(absolutePath))
{
    string content = File.ReadAllText(absolutePath);
}

The AbsolutePath struct:

• Value — the absolute path string
• OriginalValue — preserves the input path (use for error messages and [Output] properties)
• Implicitly convertible to string for File/Directory API compatibility
• GetCanonicalForm() — resolves .. segments and normalizes separators (see Sin 5)

CAUTION: GetAbsolutePath() throws ArgumentException for null/empty inputs. See Sin 3 and Sin 6 for compatibility implications.

Step 3: Replace Environment Variable APIs

Step 4: Replace Process Start APIs

Updating Unit Tests

Built-in MSBuild tasks now initialize TaskEnvironment with a MultiProcessTaskEnvironmentDriver-backed default. Tests creating instances of built-in tasks no longer need manual TaskEnvironment setup. For custom or third-party tasks that implement IMultiThreadableTask without a default initializer, set TaskEnvironment = TaskEnvironmentHelper.CreateForTest().

APIs to Avoid

Practical Notes

CRITICAL: Trace All Path String Usage

Trace every path string through all method calls and assignments to find all places it flows into file system operations — including helper methods that may internally use File System APIs.

1. Find every path string (e.g., item.ItemSpec, function parameters)
2. Trace downstream through all method calls
3. Absolutize BEFORE any code path that touches the file system
4. Use OriginalValue for user-facing output (logs, errors) — see Sin 2

Exception Handling in Batch Operations

In batch processing (iterating over files), GetAbsolutePath() throwing on one bad path aborts the entire batch. Match the original task's error semantics:

bool success = true;
foreach (ITaskItem item in SourceFiles)
{
    try
    {
        AbsolutePath path = TaskEnvironment.GetAbsolutePath(item.ItemSpec);
        ProcessFile(path);
    }
    catch (ArgumentException ex)
    {
        Log.LogError("Invalid path '{0}': {1}", item.ItemSpec, ex.Message);
        success = false;
    }
}
return success;

Prefer AbsolutePath Over String

Stay in the AbsolutePath world — it's implicitly convertible to string where needed. Avoid round-tripping through string and back.

TaskEnvironment is Not Thread-Safe

If your task spawns multiple threads internally, synchronize access to TaskEnvironment. Each task instance gets its own environment, so no synchronization between tasks is needed.

References

• Thread-Safe Tasks Spec
• AbsolutePath
• TaskEnvironment
• IMultiThreadableTask

Compatibility Red-Team Playbook

After migration, review for behavioral compatibility. Every observable difference is a bug until proven otherwise.

Observable behavior = Execute() return value, [Output] property values, error/warning message content, exception types, files written, and which code path runs.

The 6 Deadly Compatibility Sins

Real bugs found during MSBuild task migrations. Every one shipped in initial "passing" code with green tests.

Sin 1: Output Property Contamination

Absolutized values leak into [Output] properties that users/other tasks consume.

// BROKEN: ManifestPath was "bin\Release\app.manifest", now "C:\repo\bin\Release\app.manifest"
AbsolutePath abs = TaskEnvironment.GetAbsolutePath(Path.Combine(OutputDirectory, name));
ManifestPath = abs; // implicit string conversion!

// CORRECT: separate original form from absolutized path
string originalPath = Path.Combine(OutputDirectory, name);
AbsolutePath outputPath = TaskEnvironment.GetAbsolutePath(originalPath);
ManifestPath = originalPath;          // [Output]: original form
document.Save((string)outputPath);    // file I/O: absolute path

Detect: For every [Output] property, trace backward — is it ever assigned from an AbsolutePath?

Sin 2: Error Message Path Inflation

Error messages show absolutized paths instead of the user's original input.

// BROKEN: "Cannot find 'C:\repo\app.manifest'" instead of "Cannot find 'app.manifest'"
AbsolutePath abs = TaskEnvironment.GetAbsolutePath(path);
Log.LogError("Cannot find '{0}'", abs); // implicit conversion!

// CORRECT: use OriginalValue
Log.LogError("Cannot find '{0}'", abs.OriginalValue);

Detect: Search every Log.LogError/LogWarning/LogMessage — is any argument an AbsolutePath?

Sin 3: Null Coalescing That Changes Control Flow

Adding ?? "" silently swallows an exception the old code relied on for error handling.

// BEFORE: Path.GetDirectoryName("C:\") → null → Path.Combine(null, x) → ArgumentNullException
//   → task fails with an exception / error logged → Execute() returns false

// BROKEN: ?? "" added "for safety"
string dir = Path.GetDirectoryName(fileName) ?? string.Empty;
// Path.Combine("", x) succeeds silently → no error → Execute() returns TRUE!

Detect: For every ?? you added, ask: "What happened when this was null before?" If it threw and was caught → your ?? is a bug.

Sin 4: Try-Catch Scope Mismatch

GetAbsolutePath() inside a try block leaves the absolutized value out of scope in the catch block. Helper methods in the catch (like LockCheck) then use the original non-absolute path.

// CORRECT: hoist above try so catch can use it too
AbsolutePath abs = TaskEnvironment.GetAbsolutePath(OutputManifest.ItemSpec);
try {
    WriteFile(abs);
} catch (Exception ex) {
    string lockMsg = LockCheck.GetLockedFileMessage(abs);        // absolute → correct file
    Log.LogError("Failed: {0}", OutputManifest.ItemSpec, ...);   // original → user-friendly
}

Detect: For every GetAbsolutePath inside a try, check if the catch block needs the absolutized value.

Sin 5: Canonicalization Mismatch

GetAbsolutePath does NOT canonicalize. Path.GetFullPath does TWO things: absolutize AND canonicalize (.. resolution, separator normalization). If the old code used Path.GetFullPath for dictionary keys, comparisons, or display, you must add .GetCanonicalForm():

// GetAbsolutePath("foo/../bar")  → "C:\repo\foo/../bar"  (NOT canonical)
// Path.GetFullPath("foo/../bar") → "C:\repo\bar"         (canonical)

// BROKEN for dictionary keys — "C:\repo\foo\..\bar" ≠ "C:\repo\bar"
var map = items.ToDictionary(p => (string)TaskEnvironment.GetAbsolutePath(p.ItemSpec), ...);

// CORRECT
var map = items.ToDictionary(
    p => (string)TaskEnvironment.GetAbsolutePath(p.ItemSpec).GetCanonicalForm(),
    StringComparer.OrdinalIgnoreCase);

Detect: Find every Dictionary/HashSet/ToDictionary using path keys, and every place the old code called Path.GetFullPath. If canonicalization mattered, add .GetCanonicalForm().

Sin 6: Exception Type Change

Old code threw FileNotFoundException for missing files; new code throws ArgumentException from GetAbsolutePath("") before reaching the file check. Custom catch blocks filtering by exception type may be bypassed. (ExceptionHandling.IsIoRelatedException catches ArgumentException, but task-specific handlers might not.)

Detect: For every GetAbsolutePath, check what the old code threw for null/empty and whether the calling code has type-specific catch blocks.

Red-Team Audit Protocol

Phase 1: Trace Every Changed Line

For each modified line: What was the exact runtime value before? After? Where does it flow (outputs, logs, file paths, dictionary keys)? Does each destination produce identical observable behavior?

Phase 2: Null/Empty/Edge Input Analysis

Path.GetDirectoryName → Path.Combine chains:

Verify behavior on both net472 and net10.0.

Phase 3: Downstream Impact

1. Output properties: What consumes this task's [Output]? Does it compare, display, or use as a path?
2. Written files: Does file content change? (e.g., XML with embedded paths)
3. Helper methods: Do LockCheck, ManifestWriter, etc. internally resolve relative paths?
4. Error codes: MSBuild error codes (MSBxxxx) must be identical.

Phase 4: Concurrency

1. Two tasks with different ProjectDirectory values don't interfere
2. No writes to static fields (shared across threads)
3. All file operations use absolutized paths

Compatibility Test Matrix

[Task] × [Input Type] × [Assertion]

Inputs: relative path, absolute path, null, empty, ".." segments, root "C:\",
        forward slashes, trailing separator, UNC path, 260+ char path

Assertions: Execute() return value, [Output] exact string, error message content,
            exception type, file location, file content

Sign-Off Checklist

• [MSBuildMultiThreadableTask] on every concrete class (not just base — Inherited=false)
• IMultiThreadableTask on classes that use TaskEnvironment APIs, with default initializer = TaskEnvironment.Fallback
• Every [Output] property: exact string value matches pre-migration
• Every Log.LogError/LogWarning: path in message matches pre-migration (use OriginalValue)
• Every GetAbsolutePath call: null/empty exception behavior matches old code path
• Every dictionary/set with path keys: canonicalization preserved (GetCanonicalForm())
• Every try-catch: absolutized value available in catch block where needed
• Every ?? or ?. added: verified it doesn't swallow a previously-thrown exception
• No AbsolutePath leaks into user-visible strings unintentionally
• Helper methods traced for internal File API usage with non-absolutized paths
• Tests for custom tasks set TaskEnvironment = TaskEnvironmentHelper.CreateForTest() (built-in tasks have a default)
• Cross-framework: tested on both net472 and net10.0
• Concurrent execution: two tasks with different project directories produce correct results
• No forbidden APIs (Environment.Exit, Console.*, etc.)