仅使用私有NuGet源时PostSharp/Metalama的依赖还原问题

一、Metalama构建超时错误排查与解决 #

从提供的错误日志来看，核心问题是Metalama在执行编译时依赖定位时，调用dotnet build命令超过了默认120秒的超时限制：

=== File: 498a32b8-2e48-428a-83dc-fc2aa2eb3dd0.txt ===
System.AggregateException: One or more errors occurred. ---> Metalama.Framework.Engine.AssertionFailedException: The process 'C:\Program Files\dotnet\dotnet.exe build -bl:msbuild_a8e4b14d9cd24c1388877e8e61f2bb5a.binlog' did not complete in 120 s.
   at Metalama.Framework.Engine.Utilities.DotNetTool.Execute(String arguments, String workingDirectory, Int32 timeout, Func`2 environmentVariableFilter)
   at Metalama.Framework.Engine.CompileTime.CompileTimeAssemblyLocator.GetReferenceAssembliesManifest(String targetFrameworks, String additionalPackageReferences, String additionalNugetSources, String hooksDirectory)
   at Metalama.Framework.Engine.CompileTime.CompileTimeAssemblyLocator..ctor(ProjectServiceProvider& serviceProvider, String additionalReferences, ITempFileManager tempFileManager)
   at Metalama.Framework.Engine.CompileTime.CompileTimeAssemblyLocatorProvider.Metalama.Framework.Engine.CompileTime.ICompileTimeAssemblyLocatorProvider.GetInstance(ProjectServiceProvider& serviceProvider)
   at Metalama.Framework.Engine.Services.ServiceProviderExtensions.GetReferenceAssemblyLocator(ProjectServiceProvider serviceProvider)
   at Metalama.Framework.Engine.CompileTime.SystemTypeResolver..ctor(ProjectServiceProvider& serviceProvider, CompilationContext compilationContext)
   at Metalama.Framework.Engine.CompileTime.SystemTypeResolver.Provider.Create(CompilationContext compilationContext)
   at Metalama.Framework.Engine.Utilities.Caching.WeakCache`2.GetOrAdd(TKey key, Func`2 func)
   at Metalama.Framework.Engine.CompileTime.SystemAttributeDeserializer.Provider.Create(CompilationContext compilationContext)
   at Metalama.Framework.Engine.Utilities.Caching.WeakCache`2.GetOrAdd(TKey key, Func`2 func)
   at Metalama.Framework.Engine.CompileTime.SymbolClassifier..ctor(ProjectServiceProvider& serviceProvider, CompilationContext compilationContext)
   at Metalama.Framework.Engine.CompileTime.ClassifyingCompilationContextFactory.GetInstanceCore(Compilation compilation)
   at Metalama.Framework.Engine.Utilities.Caching.WeakCache`2.GetOrAdd(TKey key, Func`2 func)
   at Metalama.Framework.Engine.Pipeline.CompileTime.CompileTimeAspectPipeline.<ExecuteAsync>d__3.MoveNext()
   --- End of inner exception stack trace ---
   at System.Threading.Tasks.Task`1.GetResultCore(Boolean waitCompletionNotification)
   at Metalama.Framework.Engine.Utilities.Threading.TaskRunner.RunSynchronously[T](Func`1 func, CancellationToken cancellationToken)
   at Metalama.Framework.Engine.Pipeline.SourceTransformer.Execute(ITransformerContext context)

针对这个问题，可尝试以下解决步骤：

• 延长编译超时时间：通过环境变量METALAMA_COMPILE_TIME_ASSEMBLY_LOCATOR_TIMEOUT设置更长的超时值，比如设置为300秒（5分钟）：

  # Windows命令行
  set METALAMA_COMPILE_TIME_ASSEMBLY_LOCATOR_TIMEOUT=300
  
  # Linux/macOS终端
  export METALAMA_COMPILE_TIME_ASSEMBLY_LOCATOR_TIMEOUT=300
  

  若为CI/CD环境，直接在环境变量配置中添加该参数即可。
• 优化私有源缓存与访问：
  1. 检查NuGet.config中的globalPackagesFolder配置，确保依赖包已缓存到本地目录，避免重复从私有源拉取。
  2. 确认私有源的网络响应速度，若源本身访问缓慢，需排查网络链路或私有源服务器性能问题。
• 预编译时依赖：提前执行dotnet restore时，确保Metalama的编译时组件相关包已被还原到本地缓存，可手动将Metalama系列包推送至私有源并验证可用性。

二、为何提前执行还原后，Metalama仍需再次还原 #

Metalama的编译时逻辑需要动态生成临时项目，用于解析编译时的类型引用、框架依赖以及Aspect相关的扩展组件。这个临时项目的依赖集合与主项目并不完全一致：

• 临时项目可能需要特定版本的框架引用、Metalama内部组件依赖，这些依赖未必包含在主项目的还原范围内。
• Metalama需要验证依赖的完整性与兼容性，确保编译时的类型解析准确，因此会触发独立的还原流程，与主项目的预还原操作不冲突。

内容的提问来源于stack exchange，提问作者stan