"Exceeded retry count of 10. Failed." because of csproj misconfiguration

user_179795 0
Viewed 211

This happens randomly when trying to compile a fairly large solution with only a few dozen csprojs referencing the particular dll that fails to copy.

<ItemGroup>
    <Reference Include="SomeLabrary, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null">
        <HintPath>..\..\..\lib\some-library.dll</HintPath>
    </Reference>
</ItemGroup>

My question is, How do I tell the dotnet compiler to not copy this library, or do it once, or compare it before copying or don't lock the file in a Linux system? Ah, sanity, I miss thee.

gitlab-ci-runner .net-core c#
2 Answers

Sorry I can't comment yet, so I try an answer.

I was facing this issue in a big project as well, a couple of years ago. I tracked it down to a specific process VisualStudio is starting during compile time, which was blocking the .dll. That process however didn't seem to be required. Therefore I added a taskkill command to the post build to kill it. I don't remember what the blocking process was.

You can however do the same as me back then, and get Process Explorer, which can help you find handles.

When Process Explorer is started you can hit CTRL+F to search for a handle, you basically enter only your .dll name there. If any process has a file handle to your dll it will show up in your search. You have a pretty good chance to find that process while you're getting the "could not copy" error, it's being retried for a couple of seconds.

If you find that process you can also try a search in that context. Maybe there's a better solution than using taskkill nowadays.

user_76716710

Found the curlprit. It wasn't because of the csproj or sln files, or even the library file. It was the dotnet target configuration publish that was misbehaving. It was added around the time that I ihad restructured my solution and added /bin, /lib, /src, etc to the root directory. because it's always a good idea to change multiple things at the same time.
Removing -publish from the compiler flags fixed the issue.
Turns out battle testing by a million devs that don't have hundreds of projects in solutions doesn't bring out some bugs:)

user_1797950
Related