Errors running libman CLI commands as a pre-build step in projects building in parallel on an Azure hosted agent
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 25/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- csharp
- Domain
- build-system, cli
Research direction
Start by reproducing the two-project parallel build using the libman clean && libman restore pre-build commands and the Azure Pipelines installation steps. Inspect how concurrent CLI invocations access .librarymanager/libman.config.json; done means both projects build successfully without the file-in-use exception.
Written by the indexing model from the issue text.
Description
Functional impact
Running into errors building projects in parallel on an Azure Pipelines hosted agent when they both invoke the libman CLI as a pre-build step.
Minimal repro steps
- Create a Visual Studio solution with 2 projects that both invoke "libman clean && libman restore" as a pre-build step
- Create an Azure Pipeline that
- Uses a 'dotnet' task to install the libman CLI to Agent.ToolsDirectory
dotnet tool install Microsoft.Web.LibraryManager.Cli --tool-path="$(Agent.ToolsDirectory)" - Uses a 'Powershell' task that adds Agent.ToolsDirectory to the environment variables
Write-Host "##vso[task.setvariable variable=PATH;]${env:PATH};$(Agent.ToolsDirectory)"; - Builds the solution in parallel
- Uses a 'dotnet' task to install the libman CLI to Agent.ToolsDirectory
- Run the build on an Azure hosted agent
Expected result
Libman CLI commands run successfully
Actual result
Sometimes I see the following error output for one of the projects which causes the build to fail:
Unhandled Exception: System.TypeInitializationException: The type initializer for 'Microsoft.Web.LibraryManager.Configuration.Settings' threw an exception. ---> System.IO.IOException: The process cannot access the file 'C:\Users\VssAdministrator\.librarymanager\libman.config.json' because it is being used by another process.
Further technical details
I assume the issue is because both commands are running simultaneously and one puts a lock on libman.config.json so the other can't access it. I have run the build on a VM agent and do not see this error, though I installed libman globally on that machine so the 'install Libman CLI' step isn't part of the pipeline that runs on it.
- Dominant language
- C#
- Stars
- 486
- Forks
- 91
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from aspnet/LibraryManager
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
aspnet/LibraryManager#824 · 1 comment · 3 reactions ·
-
Difficulty 1/5 Under an hour Newbie friendliness 68/100
aspnet/LibraryManager#804 · 2 reactions ·
-
Difficulty 1/5 Under an hour Newbie friendliness 48/100
aspnet/LibraryManager#829 · 1 comment · 3 reactions ·
-
Difficulty 4/5 3-5 days Newbie friendliness 42/100
aspnet/LibraryManager#820 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
aspnet/LibraryManager#808 · 5 comments ·
All issues in aspnet/LibraryManager
Similar issues
-
bug frontend good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
NavigationViewItemAutomationPeer implements IInvokeProvider but never advertises the Invoke pattern Open
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
unoplatform/uno#24629 ·
-
agentic-workflows Needs: Triage :mag: State: In-PR
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
bug
Difficulty 1/5 Under an hour Newbie friendliness 90/100
-
Type: enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
apache/arrow-adbc#4809 ·