Hi Ivan,
I've identified a regression in com.IvanMurzak.Unity.MCP related to how script-execute handles assembly references when NuGet packages are stored in a flat directory structure.
Problem: In Tool_Script.Execute.cs, the ExecuteCSharpCode method collects metadata references using AssemblyUtils.AllAssemblies. When a project uses the flat NuGet layout (Assets/Plugins/NuGet/*.dll), the Location property of many loaded assemblies still points to the legacy versioned subdirectories. This causes MetadataReference.CreateFromFile(a.Location) to fail with FileNotFoundException or DirectoryNotFoundException.
Impact: Roslyn compilation fails with errors like CS0246: The type or namespace name '...' could not be found because critical dependencies (SignalR, Microsoft.Extensions, R3, etc.) are skipped during reference collection.
Suggested Fix: The assembly resolution logic in ExecuteCSharpCode should be more resilient. If a.Location does not exist on disk, it should check if a DLL with the same filename exists in the Assets/Plugins/NuGet/ directory and use that path instead.
Alternatively, the NuGetPackageRestorer or a dedicated assembly resolver should ensure that the AppDomain metadata or the reference list used by Roslyn is updated to reflect the flat directory structure.
Logs: Many warnings like: File not found for assembly 'Microsoft.AspNetCore.SignalR.Client' at '.../NuGet/Microsoft.AspNetCore.SignalR.Client.8.0.15/Microsoft.AspNetCore.SignalR.Client.dll' followed by compilation errors.
Hi Ivan,
I've identified a regression in com.IvanMurzak.Unity.MCP related to how script-execute handles assembly references when NuGet packages are stored in a flat directory structure.
Problem: In Tool_Script.Execute.cs, the ExecuteCSharpCode method collects metadata references using AssemblyUtils.AllAssemblies. When a project uses the flat NuGet layout (Assets/Plugins/NuGet/*.dll), the Location property of many loaded assemblies still points to the legacy versioned subdirectories. This causes MetadataReference.CreateFromFile(a.Location) to fail with FileNotFoundException or DirectoryNotFoundException.
Impact: Roslyn compilation fails with errors like CS0246: The type or namespace name '...' could not be found because critical dependencies (SignalR, Microsoft.Extensions, R3, etc.) are skipped during reference collection.
Suggested Fix: The assembly resolution logic in ExecuteCSharpCode should be more resilient. If a.Location does not exist on disk, it should check if a DLL with the same filename exists in the Assets/Plugins/NuGet/ directory and use that path instead.
Alternatively, the NuGetPackageRestorer or a dedicated assembly resolver should ensure that the AppDomain metadata or the reference list used by Roslyn is updated to reflect the flat directory structure.
Logs: Many warnings like: File not found for assembly 'Microsoft.AspNetCore.SignalR.Client' at '.../NuGet/Microsoft.AspNetCore.SignalR.Client.8.0.15/Microsoft.AspNetCore.SignalR.Client.dll' followed by compilation errors.