Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Seeminlgly random LIB003 #697

Open
leotsarev opened this issue Jun 29, 2022 · 10 comments
Open

Seeminlgly random LIB003 #697

leotsarev opened this issue Jun 29, 2022 · 10 comments

Comments

@leotsarev
Copy link
Contributor

Describe the bug

I got seemingly random
libman.json : error LIB003: XXXXX could not be written to disk. Make sure the file name is correct

XXX is different files, and sometimes it works.
It could be related with #489, but I don't pass runtime option and just use dotnet build -c Release --no-restore

Additional context

https://github.com/joinrpg/joinrpg-net/runs/7111112857?check_suite_focus=true

@leotsarev
Copy link
Contributor Author

leotsarev commented Jun 29, 2022

I try to read code and I don't like how FileSystemHelper and HostIteraction consuming errors without logging. May be we should expand logging here? Will you welcome contribution?

@TFTomSun
Copy link

TFTomSun commented Sep 8, 2022

We get that error sporadically as well, finding out the root cause would be helpful.

@n1njab0b
Copy link

We are experiencing this in our CI/CD pipeline as well. Sometimes it works, sometimes half the files get written before we receive the LIB003 error. This is really problematic for us as our CI/CD build/test stages sporadically fail now that we have introduced libman into our project.

@n1njab0b
Copy link

It might be helpful to know that in our environment, the sporadic failures are happening when we utilize the "Enable Restore Client-Side Libraries on Build" feature and the build server performs either a dotnet build or dotnet test.
To temporarily work around this issue while we wait for a fix, we disabled the "Restore Client-Side Libraries on Build" feature and are now manually performing a libman restore in each project folder. This seems to be working for us, so that would suggest to me that the problem is somehow stemming from the Microsoft.Web.LibraryManager.Build package.

@leotsarev
Copy link
Contributor Author

@jimmylewis what do you think is correct path forward? Can I help?

@leotsarev
Copy link
Contributor Author

@jimmylewis ?

@icnocop
Copy link

icnocop commented Dec 4, 2023

This started happening for me when the project which was failing was updated to target multiple frameworks:
<TargetFrameworks>netcoreapp3.1;net6.0;net8.0</TargetFrameworks>

As a work-around, I had to run libman restore before a build.

Another work-around could be to disable parallel builds either on the project level or the solution level.

@alexhiggins732
Copy link

Same issue here, using enable package restore on build. No parallel jobs running. Get intermittent failures on local windows and on Ubuntu via the github workflow build, for various JS files. Seems to be a lingering issue going back some time according to posts on stack overflow.

I am looking to remove the source code from the repo and allow users to use LibMan to install the packages upon build to cleanup the repository.

@DrMueller
Copy link

+1 here, randomly happens during a restore in the azure devops pipeline on a self hosted VM.

@brecht-yperman-uz
Copy link

I recently started getting these errors as well. They seemingly started when we switched from McAfee to Microsoft Defender, though that may be a post hoc fallacy. There are no errors in the Defender logs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants