format
format copied to clipboard
What does "Found project reference without a matching metadata reference" indicate?
I get a lot of these warnings and I just want to make sure everything is OK. Can this be documented somewhere if it should be addressed, am I not following a best practice possibly, or should I ignore this?
Version: 3.0.2+658b525df6382ed33b20345ba5b037c8515c9a71
I believe this is coming from MSBuildWorkspace @DustinCampbell ?
It's when there's a project reference in a project that can't be matched up with an output path (code). I would guess this is happening with multi-targeted projects?
I would guess this is happening with multi-targeted projects?
That is where I observed it happening (in roslyn anyway). For the purposes of dotnet-format do you think it is safe to not report this case?
Sure. I think it's safe not to report it in dotnet-format
I'm getting this too. MVC5 apps point to some class libraries and it comes up for a few of my class libraries that are just net472 targeted. Those class libraries point to nuget packages that have multiple targets, but other than that they are fairly standard.
I see this message when I run dotnet format in workspace with a solution. I even see it when I run it in a project subdirectory that's associated with a solution (using -w). I don't know if the solution is relevant, but I never create projects without one, so... 🤷♂
As for multi-targeting, these projects are all netcoreapp2.2 only.
Closing this issue now that Project load warnings are only logged during when the log level is set to verbose.
@JoeRobich Actually, I think this is something that should be solved by dotnet-format. Although, these warnings only show up when you set the log level to verbose, you do get a hint of them with the default log level, it shows up as:
Warnings were encountered while loading the workspace. Set the verbosity option to the 'diagnostic' level to log warnings.
The sole reason I found out about the given warning is that my project now always has this warning, and I had to dig in to find out what the problem was, and to finally find out that this is something I can ignore. So this also means that I'll always will receive this warning, even though, I cannot fix it. This will lead to "more broken windows" as when more warnings show up, I wouldn't know, since I wouldn't give any attention to the fact that I have warnings.
I think we should not still log this in verbose mode, but not tell the user that the project loaded with warnings if this is the only warning kind encountered. I think most of this work with require changes in roslyn but we'll track this here.
It seemed I met the same problem, there's a sample build https://github.com/WeihanLi/WeihanLi.Common/runs/4709669170?check_suite_focus=true , and I expect dotnet-format would format my code with file header template, but nothing happens, can be reproduced with the code https://github.com/WeihanLi/WeihanLi.Common/tree/d64ce840ed0bf8f076b6706dc107bc9e80787e31
When I run dotnet format, I would get output like follows:
Warnings were encountered while loading the workspace. Set the verbosity option to the 'diagnostic' level to log warnings.
When I specific the -v=diag, I would get some Found project reference without a matching metadata reference from the output, not sure if it's the same issue, and some projects are not using the editor config in the repo, is it expected?
PS C:\projects\sources\WeihanLi.Common> dotnet format -v=diag
The dotnet runtime version is '6.0.1'.
The dotnet CLI version is '6.0.101'.
Using MSBuild.exe located in 'C:\Program Files\dotnet\sdk\6.0.101\'.
Formatting code files in workspace 'C:\projects\sources\WeihanLi.Common\WeihanLi.Common.sln'.
Loading workspace.
Determining projects to restore...
All projects are up-to-date for restore.
Found project reference without a matching metadata reference: C:\projects\sources\WeihanLi.Common\src\WeihanLi.Data\WeihanLi.Data.csproj
Found project reference without a matching metadata reference: C:\projects\sources\WeihanLi.Common\src\WeihanLi.Common.Aspect.AspectCore\WeihanLi.Common.Aspect.AspectCore.csproj
Found project reference without a matching metadata reference: C:\projects\sources\WeihanLi.Common\src\WeihanLi.Common.Aspect.Castle\WeihanLi.Common.Aspect.Castle.csproj
Found project reference without a matching metadata reference: C:\projects\sources\WeihanLi.Common\src\WeihanLi.Common.Logging.Log4Net\WeihanLi.Common.Logging.Log4Net.csproj
Found project reference without a matching metadata reference: C:\projects\sources\WeihanLi.Common\src\WeihanLi.Common.Logging.Serilog\WeihanLi.Common.Logging.Serilog.csproj
Project WeihanLi.Common(netstandard2.0) is using configuration from 'C:\projects\sources\WeihanLi.Common\.editorconfig'.
Project WeihanLi.Common(netstandard2.0) is using configuration from 'C:\projects\sources\WeihanLi.Common\src\WeihanLi.Common\obj\Debug\netstandard2.0\WeihanLi.Common.GeneratedMSBuildEditorConfig.editorconfig'.
Project WeihanLi.Common(netstandard2.1) is using configuration from 'C:\projects\sources\WeihanLi.Common\.editorconfig'.
Project WeihanLi.Common(netstandard2.1) is using configuration from 'C:\projects\sources\WeihanLi.Common\src\WeihanLi.Common\obj\Debug\netstandard2.1\WeihanLi.Common.GeneratedMSBuildEditorConfig.editorconfig'.
Project WeihanLi.Common(net6.0) is using configuration from 'C:\projects\sources\WeihanLi.Common\.editorconfig'.
Project WeihanLi.Common(net6.0) is using configuration from 'C:\projects\sources\WeihanLi.Common\src\WeihanLi.Common\obj\Debug\net6.0\WeihanLi.Common.GeneratedMSBuildEditorConfig.editorconfig'.
Project WeihanLi.Common(net6.0) is using configuration from 'C:\Program Files\dotnet\sdk\6.0.101\Sdks\Microsoft.NET.Sdk\analyzers\build\config\analysislevel_6_default.editorconfig'.
Project WeihanLi.Common.Test is using configuration from 'C:\projects\sources\WeihanLi.Common\.editorconfig'.
Project WeihanLi.Common.Test is using configuration from 'C:\projects\sources\WeihanLi.Common\test\WeihanLi.Common.Test\obj\Debug\net6.0\WeihanLi.Common.Test.GeneratedMSBuildEditorConfig.editorconfig'.
Project WeihanLi.Common.Test is using configuration from 'C:\Program Files\dotnet\sdk\6.0.101\Sdks\Microsoft.NET.Sdk\analyzers\build\config\analysislevel_6_default.editorconfig'.
Same as @WeihanLi. If the warning is ignorable, and only emitted in diagnostic level, it needs to not trigger "Warnings were encountered while loading the workspace."
I had this same problem, and the cause ended up being the project order in the solution file. For anyone experiencing this warning, I would encourage you to check if the referenced project is listed after the project which includes the <ProjectReference Include="..."/> statement in the solution file.
I had this same problem, and the cause ended up being the project order in the solution file. For anyone experiencing this warning, I would encourage you to check if the referenced project is listed after the project which includes the
<ProjectReference Include="..."/>statement in the solution file.
Thanks @jameschensmith, putting the referenced project before the one that references it in the solution file made disappear the warning for me.
thanks @jameschensmith - same here, the warning disappeared after changing the order of projects in the SLN file. In my case the solution is a mix of .NET Standard 2.0, .NET 6 and 7. The project using 2.0 was triggering the warning, and moving it to the top made the warning disappear.
Looks like a minor bug, but it would be nice to have it fixed. Any warning like "Warnings were encountered while loading the workspace. Set the verbosity option to the 'diagnostic' level to log warnings" can trigger CI build failures, and having to sort files (manually) in a SLN file doesn't looks like something developers should have to worry about.
This error seems to occur when referencing a subproject that targets netstandard2.0 or netstandard2.1.
It can be resolved by adding ProduceReferenceAssembly MSBuild property to true.
https://github.com/dotnet/format/blob/91f60316ebd9c75d6be8b7f9b7c201bab17240c9/src/Workspaces/MSBuildWorkspaceLoader.cs#L26-L32
ProduceReferenceAssembly property is set by default for target net5.0 or later.
But netstandard2.0 or netstandard2.1 projects use false for backward compatibility.
It seems that an attempt was made to set this property by default for all target frameworks, But it's reverted later for compatibility issue. https://github.com/dotnet/msbuild/pull/8571