fix: handle multiple csproj files better

[seblyng]

@ownself

Do you have some reproducible steps to this:

In Unity project, there will be one sln and tons of csproj files laying down in the root folder, Unity Editor is in charge of updating them during the development, and if someone decide to tweak the "Regenerating csproj" setting in "Preference->External Tool", that potentially left some csproj not belong to that sln, in that senario, Roslyn.nvim occasionally malfunction once or twice by mis-selecting the inco

and can test if this fixes it?

I believe it should handle dirty csproj files a bit better

[seblyng]

This will cause it to search a bit more, but I don't believe this is something that will be noticed in the performance since it is searching upward

[ownself]

Yes! This is definately the right direction. I did the exactly same fix on my fork, but it's only one of the issues I met with.
My fork has already fixed all the major issue I had, but the code's a bit of chaos right now, I'm planning a clean refactoring after Chinese New Year Vacation. I will let you know once that's done.
You can see if there is anything worth to copy then.

[ownself]

Hello, seblyng:

This weekend I finally had enough uninterrupted time to fully fix and refine the sln/csproj logic. The scope of the changes turned out to be fairly large. For quite a while, I had been struggling with how to improve the logic without making overly significant changes, so that it would be easier both for me to submit as a PR and for you to review. In the end, however, I realized that there seems to be a fairly large gap between our understandings of what the plugin should and should not do. Because of that, I probably will not be submitting PRs to you anymore in the future, and this also means I now feel free to make larger adjustments to the plugin’s current logic.

Since I genuinely believe there are many issues in the current plugin’s handling of sln/csproj files—especially for Unity projects—I’d like to summarize here what I have observed and what I have changed. Of course, I just hope my still immature suggestions will not come across as laughable :)

Regarding the sln/csproj logic, the current plugin has the following issues:

• lock_target is not persisted to disk, so in practice its only benefit is a slight improvement in performance when determining root_dir while opening a buffer. At the same time, it sacrifices the ability to open multiple different sln files within the same session.
• root_dir and on_init each execute their own logic to search for and locate the directory and sln independently, which can lead to potential inconsistencies as well as timing-related logic issues.
• When multiple sln files exist and the logic cannot determine which one should be used, the decision should be left to the user, rather than falling back bluntly to the csproj path or treating it as a failure.
  • choose_target is not really an ideal solution. Hardcoding project-opening behavior directly in configuration is not flexible enough.
• When the plugin cannot determine which sln to use among multiple sln files, it falls back aggressively to opening all csproj files it can find. In Unity projects, this causes extremely poor performance.
• When searching for csproj files, there is a chance of finding the wrong csproj file (which is exactly the issue being discussed in this thread).

The general idea and flow of my first round of refactoring are as follows (though there may still be details that need improvement):

• If exactly one solution is found, return the solution directory directly and cache it as a solution.
• Otherwise, continue searching upward for .csproj files.
• If no .csproj is found:
  • If there are multiple solutions, prompt the user to choose a solution.
  • If there are no solutions, return nil.
• If .csproj files are found, use them to filter the solutions:
  • If only one solution remains after filtering, return the solution directory and cache it as a solution.
  • If multiple solutions still remain after filtering, prompt the user to choose a solution.
  • If no solutions remain after filtering:
    • If there is exactly one .csproj, return the project directory and cache it as a project.
    • If there are multiple .csproj files, prompt the user to choose a project.
• on_init no more searches sln/csproj, it just uses the cached "root_dir -> sln/csproj" to initialize the LSP client