Migrate Tlblmp and AxImp to Multithreaded Execution#13708
Conversation
AlesProkop
changed the title
There was a problem hiding this comment.
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.TlbImpas[MSBuildMultiThreadableTask]and updated its command-line generation to absolutize key path inputs viaTaskEnvironment.GetAbsolutePath(). - Updated
AxTlbBaseTaskto validate/tool-resolve usingTaskEnvironment-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. |
|
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 |
AlesProkop
changed the title
JanProvaznik
left a comment
JanProvaznik
left a comment
There was a problem hiding this comment.
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. |
| private bool DirectoryExists(string path) | ||
| { | ||
| AbsolutePath absolutePath = TaskEnvironment.GetAbsolutePathIfValid(path); | ||
| return absolutePath.Value != null && FileSystems.Default.DirectoryExists(absolutePath); |
There was a problem hiding this comment.
probably have same issue as FileInfoExists
There was a problem hiding this comment.
Also, I would have expected that DirectoryExists does exactly the same as FIleExists helper, but it is different.
There was a problem hiding this comment.
Yes, it is not symmetric, it was like that before the migration, I can rename the function if you think it will be better for readability.
Fixes #13633
Fixes #13626
Context
TlbImpis an internal nestedToolTaskused byResolveComReferenceto wrapTlbImp.exe. This change marks the concreteTlbImptask as safe for MSBuild's multithreaded task model and audits the sharedAxTlbBaseTaskbase class used by bothTlbImpandAxImp.Changes Made
Annotated
TlbImpwith[MSBuildMultiThreadableTask].Annotated
AxImpwith[MSBuildMultiThreadableTask], since it is the other concrete task derived fromAxTlbBaseTask.Audited
AxTlbBaseTaskand routed file-system checks throughTaskEnvironment.GetAbsolutePath()for:ToolPathSdkToolsPathKeyFileKept tool command-line path arguments verbatim intentionally:
TypeLibNameOutputAssemblyReferenceFilesActiveXControlNameRuntimeCallableWrapperAssemblyKeyFilewhen passed toTlbImp.exe/AxImp.exeThese are resolved by the spawned tool relative to the task environment working directory provided by
ToolTask, avoiding user-visible path inflation.Did not migrate
ResolveComReferenceitself 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 viaTaskEnvironment.GetProcessStartInfo(), and task environment variable handling are provided by the sharedToolTaskbase infrastructure.Testing
src\Tasks\Microsoft.Build.Tasks.csprojsuccessfully.GetAssemblyIdentitytests:Microsoft.Build.Tasks.UnitTests.exe --filter-class Microsoft.Build.UnitTests.GetAssemblyIdentity_Tests --no-progress