PS0216: Machine-Wide Lock Cannot Be Acquired

Cause

Several builds can run PostSharp at the same time on one machine. When PostSharp writes to a file of its caches, such as the assembly cache, the facade assemblies and the type indexes in the directory of the PostSharpCacheDirectory MSBuild property, it first acquires a named lock of the operating system (a named mutex on Windows), so that two builds do not write the same file at the same time.

PostSharp reports PS0216 when the operating system throws an exception while PostSharp opens or acquires this lock. <Name> is the name of the lock: a Global\PostSharp_ prefix followed by a hash of the directory and of the file that the lock protects. <Reason> is the message of the exception. A common reason is that the lock was created by a process of another user account, for example a build service, that does not grant access to the current user.

PostSharp continues without the lock, so the build does not fail. However, the cache file is no longer protected from a concurrent build.

When the lock is only held by another build for longer than the waiting time, PostSharp does not report PS0216.

This message depends on the processes and the user accounts of the machine, so no example can show it.

Resolution

• When builds run under several user accounts on the same machine, give each account its own cache directory with the PostSharpCacheDirectory MSBuild property or environment variable. The name of the lock is derived from the directory, so the builds no longer share locks. See Well-Known MSBuild Properties.
• Otherwise, stop the processes that hold the lock: close the instances of Visual Studio and MSBuild of the other users, run dotnet build-server shutdown, or restart the machine.
• When the warning appears once and the build succeeds, you can ignore it. If a build fails later with an unexpected error that names a file of the cache, delete the cache directory and build again.

See Also

Other Resources

Well-Known MSBuild Properties