LAMA0083: The resolution of the compile-time reference assemblies timed out

Cause

Before it compiles your aspects, Metalama must know exactly which APIs compile-time code can use. To find out, it generates a small project under the Metalama temporary directory, then restores and builds it in a separate process. The result is cached, so this build normally runs only once per combination of settings.

Metalama gives this build a time budget, set by the MetalamaReferenceAssemblyRestoreTimeout MSBuild property, which defaults to 120,000 milliseconds. Metalama reports LAMA0083 when the build doesn't complete within this budget, and it stops the build. In the message, <ProjectPath> is the path of the generated project, <Seconds> is the timeout in seconds, <TimeoutPropertyName> is the name of the MSBuild property, and <BinaryLogPath> is the path of the binary log of the build.

The usual causes are a slow network or slow NuGet feeds, a first build on a machine with an empty NuGet cache, or a feed that doesn't respond. When the build fails instead of timing out, Metalama reports LAMA0082.

This diagnostic depends on the build environment of the machine, so it can't be shown in an example.

Resolution

• If the build is only slow, raise the timeout by setting the MetalamaReferenceAssemblyRestoreTimeout property, in milliseconds, in your project file or in a Directory.Build.props file. For instance, <MetalamaReferenceAssemblyRestoreTimeout>600000</MetalamaReferenceAssemblyRestoreTimeout> sets the timeout to ten minutes.
• If the build hangs, open the binary log given in the message, if it was written, with the MSBuild Structured Log Viewer to find the step that blocks it. A NuGet feed that doesn't respond is a frequent cause. Verify that the feeds in your nuget.config files are reachable from the machine.

Once the build succeeds, its result is cached, and later builds don't run it again.

See also

• Restoring compile-time dependencies
• LAMA0082
• MSBuild properties and environment variables