Migrate Tlblmp and AxImp to Multithreaded Execution

[AlesProkop]

Fixes #13633
Fixes #13626

Context

TlbImp is an internal nested ToolTask used by ResolveComReference to wrap TlbImp.exe. This change marks the concrete TlbImp task as safe for MSBuild's multithreaded task model and audits the shared AxTlbBaseTask base class used by both TlbImp and AxImp.

Changes Made

• Annotated TlbImp with [MSBuildMultiThreadableTask].

• Annotated AxImp with [MSBuildMultiThreadableTask], since it is the other concrete task derived from AxTlbBaseTask.

• Audited AxTlbBaseTask and routed file-system checks through TaskEnvironment.GetAbsolutePath() for:

  • ToolPath
  • SdkToolsPath
  • KeyFile

• Kept tool command-line path arguments verbatim intentionally:

  • TypeLibName
  • OutputAssembly
  • ReferenceFiles
  • ActiveXControlName
  • RuntimeCallableWrapperAssembly
  • KeyFile when passed to TlbImp.exe / AxImp.exe

  These are resolved by the spawned tool relative to the task environment working directory provided by ToolTask, avoiding user-visible path inflation.

• Did not migrate ResolveComReference itself in this PR. That task is broader and AppDomain/current-directory/cache-path sensitive, so it should be handled separately.

Notes

IMultiThreadableTask, TaskEnvironment, process launch via TaskEnvironment.GetProcessStartInfo(), and task environment variable handling are provided by the shared ToolTask base infrastructure.

Testing

• Built src\Tasks\Microsoft.Build.Tasks.csproj successfully.
• Ran focused GetAssemblyIdentity tests:
  • Microsoft.Build.Tasks.UnitTests.exe --filter-class Microsoft.Build.UnitTests.GetAssemblyIdentity_Tests --no-progress
  • Result: 9 passed, 0 failed

[Copilot]

Pull request overview

This PR aims to make the COM interop wrapper ToolTasks (notably the nested ResolveComReference.TlbImp, via shared AxTlbBaseTask) safe under MSBuild’s multithreaded task execution model by removing reliance on global process state for path handling.

Changes:

• Marked ResolveComReference.TlbImp as [MSBuildMultiThreadableTask] and updated its command-line generation to absolutize key path inputs via TaskEnvironment.GetAbsolutePath().
• Updated AxTlbBaseTask to validate/tool-resolve using TaskEnvironment-based absolute paths (ToolPath/SdkToolsPath/KeyFile).
• Updated unit tests to assert the new absolutized command-line arguments.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
src/Tasks/TlbImp.cs	Adds multithreadable annotation and absolutizes TypeLibName/OutputAssembly/ReferenceFiles in generated command line.
src/Tasks/AxTlbBaseTask.cs	Absolutizes tool path resolution and strong-name key file handling/validation using TaskEnvironment.
src/Tasks.UnitTests/TlbImp_Tests.cs	Updates expectations to match absolutized /reference, TypeLibName, and /out: arguments.
src/Tasks.UnitTests/AxTlbBaseTask_Tests.cs	Updates /keyfile: expectation to match absolutized KeyFile argument.

[AlesProkop]

Reversed some changes. I am not sure about the scope of this ticket. @AR-May please, could you specify what exactly has to be migrated? (There are two classes depending on this one, and there is also ResolveComReference)

[AR-May]

Reversed some changes. I am not sure about the scope of this ticket. @AR-May please, could you specify what exactly has to be migrated? (There are two classes depending on this one, and there is also ResolveComReference)

@AlesProkop I would suggest to enlighten both derived classes. There is no need to do it in separate pr, as those seems very similar and seems trivial for migration to me. We need to check how they are used in ResolveComReference, but I think so far as we have fallback defined everything should be correct. I suggest not to migrate ResolveComReference in this PR.

[JanProvaznik]

I don't see much value in this migration without migrating the whole ResolveComReference chain.

These tasks are never created by the TaskFactory system and routed, they're explicitly instantiated during ResolveComReference

[AR-May]

I don't see much value in this migration without migrating the whole ResolveComReference chain.

These tasks are never created by the TaskFactory system and routed, they're explicitly instantiated during ResolveComReference

I rather thought that this pr would be the first step toward migrating ResolveComReference as next action.