phmonte / Buildalyzer

A utility to perform design-time builds of .NET projects without having to think too hard about it.
MIT License
589 stars 92 forks source link

Build/assembly reference not found errors due to random sorting of the projects in the Workspace when loading projects from solution file #241

Closed hideintheclouds closed 6 months ago

hideintheclouds commented 6 months ago

There seems to be a problem in the way the projects from a solution are loaded into the workspace.

When part of a solution, the projects might have dependencies and they will require a certain build order. When getting the Workspace, it seems that the workspace is randomly building them.

      this.Workspace = Manager.GetWorkspace();

As a result of this behaviour, there are assembly reference errors that appear in some of the projects' compilation as severity=error diagnostics.

Please have a look at the following bug for a detailed explanation and for some possible workarounds, including a method to returned a sorted Workspace (GetOrderedWorkspace)

daveaglick commented 6 months ago

Please have a look at the following bug

Was there supposed to be a log file or bug linked here? If so, I don't see it.

Is the problem here that the build itself isn't correctly ordered? We just "shell out" to MSBuild or dotnet build so any project ordering based on the reference graph is the responsibility of MSBuild.

Or am I misunderstanding the problem? Is it that projects are being added into the Roslyn Workspace in an order where some are relying on references from others that haven't been added yet? If this is the case, how could we determine the "correct" order?

Perhaps most importantly is whether there's a reproduceable example of this problem. It'll be hard for me to diagnose and verify a fix without one.

hideintheclouds commented 6 months ago

Hi Dave, I updated the initial text with the proper url. I suspect the problem is somehow similar to the second option that you mentioned.

I encountered the issue on a private solution with multiple csproj files, and unfortunately cannot share the source code.

I think that the issue was reported initially using the eShopOnContainers solution as specified in the referenced url.

daveaglick commented 6 months ago

I think I'm starting to understand the issue after reading the link. I'll implement the fix identified in that thread and see if it helps.

daveaglick commented 6 months ago

Buildalyzer 6.0.2 is rolling out to NuGet now. Can you test it when you get the chance (you might need to reference the latest version explicitly in your project if you're getting it transitively through LivingDocumentation)?

hideintheclouds commented 6 months ago

Trying the 6.0.2 did not fix the issue. Now the projects always come in the same order in the AdhocWorkspace, but it seems not to find namespaces in the build dependencies (as before). Note: I was however able to have a working solution using the extension method that @AndreasKim created.

I believe the difference is made by the following:

foreach (AnalyzerResult result in results)
            {
                if (!workspace.CurrentSolution.Projects.Any(p => p.FilePath == result.ProjectFilePath))
                {
                    result.AddToWorkspace(workspace, true);
                }
            }

            return workspace;

When calling the AddToWorkspace with addProjectReferences=true, it seems to add results to the workspace, but also rebuilding and adding the referenced projects. I even commented out the sorting of the projects, and it still works when calling result.AddToWorkspace(workspace, true);

daveaglick commented 6 months ago

Of course that's the one little bit I accidentally left out :). I added that flag and 6.0.3 is rolling out now. Hopefully that resolves it once and for all, do you mind checking one more time?

hideintheclouds commented 6 months ago

6.0.3 tag seems to point to the same commit as 6.0.2: https://github.com/daveaglick/Buildalyzer/releases

I imagine that 6.0.3 should be associated with a new commit corresponding to the change?

daveaglick commented 6 months ago

Whops! I got carried away and published the release before committing the code. I publish locally so the 6.0.3 up on NuGet actually does have the change, I just need to update the tag.

hideintheclouds commented 6 months ago

Thanks, it seems to be working fine with 6.0.3, I guess that parameter made a difference