LAMA0082: Metalama can't resolve the compile-time reference assemblies

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, TempProject.csproj, under the Metalama temporary directory, then restores and builds it in a separate process with dotnet build, or with MSBuild.exe when your project is built without a .NET SDK. The result is cached, so this build normally runs only once per combination of settings.

Metalama reports LAMA0082 when this build exits with an error. In the message:

• <ProjectPath> is the path of the generated project and <ExitCode> is the exit code of the build.
• <ReportedErrors> quotes the errors that the build reported, or its last output lines when it reported no recognizable error.
• <ProbableCause> describes the probable cause when Metalama recognizes it in the output, for instance a missing package (NU1101), an unreachable feed (NU1301), a feed with an HTTP address (NU1302), an authentication error, a .NET SDK that's too old (NETSDK1045), or a global.json file that requests a .NET SDK that isn't installed. Otherwise, it's a generic sentence.
• <BinaryLogPath> is the path of the MSBuild binary log of the failed build.

The failure is almost always caused by the environment rather than by a defect of Metalama. The most frequent causes are:

• A NuGet feed that requires credentials. The build runs in a separate process, which can't ask for credentials interactively.
• A packageSourceMapping rule in nuget.config that routes Microsoft.CodeAnalysis.* packages to a private feed that doesn't carry them. The generated project inherits your nuget.config files.
• A global.json file that requests a .NET SDK version that isn't installed.
• No network access to the configured feeds.

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

Resolution

1. Read the quoted errors and the probable cause in the message. They usually point to the fix directly.
2. If they aren't enough, open the binary log given in the message with the MSBuild Structured Log Viewer to see exactly what failed.
3. Fix the environment, depending on the cause:
   • Make the credentials of private feeds available without user interaction, for instance in a nuget.config file or through a credential provider.
   • In your packageSourceMapping, map Microsoft.CodeAnalysis.* packages to a source that provides them, such as nuget.org.
   • Install the .NET SDK version requested by global.json, or change global.json.
   • If the generated project needs additional MSBuild configuration in your environment, use the MetalamaAssemblyLocatorHooksDirectory property.
4. Build again.

See also

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