v6.18.0 breaks workflows in Unity projects

[sm-quasar]

Describe the bug
v6.18.0 fails to locate an MSBuild project file or solution file and is unable to test our C# scripts and thus cannot validate them.

Unhandled exception: System.IO.FileNotFoundException: Could not find a MSBuild project file or solution file in '/github/workspace'

After the upgrade to the .18 release our megalinter workflow began reporting warnings instead of failing/fixing PRs. We currently run it just against changed files in a Unity project ( this potentially puts us in an odd position as we have no .csproj or .sln committed since Unity will auto gen these and regularly stomps over them making for messy commit history). This was all working fine for us in V6.17.0 But something in the updated version has broken the flow (.Net 6 support maybe?)

For now we've returned to the .17 release but that obviously isn't what we'd like to do long term

To Reproduce
Steps to reproduce the behavior:

1. Create a unity project
2. Add some .cs scripts
3. Add megalinter github action workflow to validate all changed files
4. Observe the below error
   Unhandled exception: System.IO.FileNotFoundException: Could not find a MSBuild project file or solution file in '/github/workspace'

See attached logs

Expected behavior
Dotnet Format should have ran against the .cs files without error or warning

Additional context
Attached logs from the two versions in question and our yml file

v6.17.0 Log
SUCCESS-CSHARP_DOTNET_FORMAT.log

v6.18.0 Log
WARNING-CSHARP_DOTNET_FORMAT.log

Our .mega-linter.yml file (renamed for github's own sanity)
mega-linter.txt

[Kurt-von-Laven]

Thank you for the report. What version of .NET are you on? What happens when you pass the workspace argument referenced in the error message? In the meantime, I will share how we use MegaLinter with .NET in case it proves helpful to you or others as either a temporary or long-term workaround. We have long found that CSharpier, just added in v6.18.0 thanks to the hard work of @bdovaz, is a much faster linter than dotnet-format. CSharpier automatically fixes all issues it detects, requires little to no configuration, and personally I find its style more readable than dotnet-format's defaults. The two linters are by-and-large redundant with one another, and dotnet-format was by far our slowest linter, so we disabled it to create a speedy .NET flavor that we can run locally on every commit and push. If you aren't wedded to dotnet-format but weren't put off by its performance and want something less opinionated than CSharpier, ReSharper's CleanupCode is extremely feature rich and flexible and not limited to C#/F#. It isn't included in MegaLinter, so it would need to be run separately or as a plugin.

[sm-quasar]

Unity is a pinch awkward in terms of .NET version, I believe I'm currently using .NET Standard 2.1 but could migrate to .NET 4.8
(Unity is quite out of date unfortunately)

I'll take a look at CSharpier, I'm not particularly married to either as long I can keep using it to apply standards automatically I'm very happy :)

[Kurt-von-Laven]

In that case, I believe your original hypothesis was correct, and you were broken by the upgrade to .NET 6. I don’t believe it will be feasible for you to run dotnet-format via recent versions of MegaLinter while on .NET Standard 2.1. I don’t know enough to advise whether migrating to .NET 4.8 would be sufficient, so that might be a question for Stack Overflow if it matters to you. Let us know if you have any feedback regarding running CSharpier via MegaLinter. Hope you find it as helpful as we have!

[echoix]

.NET Standard 2.1 is closer to .NET 6 than .NET Framework 4.8 is to .NET 6.
.NET Framework is (part of) the original, old .NET.
Then came .NET core, a complete rewrite from scratch of .NET, open source and cross platform, by using everything that they learned in the decades of software development.

So in the timeline, .NET core were released, versions 1.0, 1.1, 2.0, 2.1, 2.2, 3.0, 3.1, and there was some extra work on .NET framework versions like 4.7 and 4.8 before stopping at 4.8.
In the time when both .NET core and .NET framework coexisted (and they still coexist in the wild), a way to have some code compatible between the two needed to exist. Imagine libraries for example, they should be able to be used by all. So that's where .NET standard came. .NET standard isn't really a release of .NET, it's a base specification of APIs that are common to both .NET core versions and .NET Framework versions. To run code that targets .NET Standard, it needs a .NET runtime that implements that .NET standard version.

That seemed like a good idea, until it was just more confusing than anything, and .NET core was really there to stay. At the same time, to prevent any confusion, the release following .NET core 3 was .NET 5, and the .NET core project was renamed to .NET (without changing pas releases). Now, since .NET 5, the concept of .NET Standard is left behind in favour of a new mechanism to assure compatibility with other releases starting with .NET 5. I don't understand that mechanism yet since a couple years.

There will be no more .NET Standard releases, but MS and Dotnet as an organization sticks to their old promises and keeps it working as promised.

https://learn.microsoft.com/en-us/dotnet/standard/net-standard?tabs=net-standard-1-0

https://dotnet.microsoft.com/en-us/platform/dotnet-standard

https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core

So following this, if the Unity project and code was made for .NET Standard 2.1, and worked with .NET 5 (.NET 5 was the implemented of .NET Standard 2.1 in the previous MegaLinter release 6.17), there is no real reason for it to not work with .NET 6 in this MegaLinter release 6.18. Thus, I suspect something else, or that the dotnet format needs absolutely to load the code and project with the specific version of the dotnet SDK that the project is defined.

[echoix]

I hope this makes a good fast overview of the history for @nvuillam and @bdovaz that were often wondering how the dotnet environnement worked.

[sm-quasar]

Thanks all for the info :) and a great reminder of .NETs history

This definitely seems to be a dotnet format issue rather than a Megalinter issue (that said a breaking change version may indicate the ramifications of the .NET 6 upgrade clearer).

The only thing I see left that could be an ML issue that might need fixing is that this all gets reported as a warning and thus our workflow continued passing despite unhandled exceptions when running dotnet format

For now I'll look at CSharpier and whether I agree with it's heavily opinionated format or if for now I'll stick on megalinter version 6.17.0 for now

The final option I can look at is to force the generation of the csproj files before running megalinter, it's possible with Unity to do this but it's slow as you incur the cost of a project import (several hours for big projects)

Thanks again all

[nvuillam]

@echoix that's indeed very interesting, I never did a single line in C# and never used .NET env, so I'm a total newbie in the topic, and i'm very glad to have you and MegaLinter community to provide support on it :)

@sm-quasar > @bdovaz is himself a Unity developer, and he's at the origin of CSharper integration within MegaLinter, so switching to CSharpier is probably a good idea :)

[sm-quasar]

Good to know :) Yea I ran a pass of it this morning and wow is it fast! I only did a quick check of it's formatting but it largely looked like I wanted anyway so I probably will switch to, though may still using an .editorconfig to help with naming conventions in IDEs at least

[bdovaz]

As @nvuillam says I am a professional Unity developer (+10 years) and in our workflow we use dotnet-format but as we already had it before Megalinter, we have it integrated outside of it.

Let's see if I find the time and test it from Megalinter to see if it gives us problems or not.

In our case the project is Unity 2021.3.x (LTS) + .NET Standard 2.1.

[sm-quasar]

@bdovaz Nice, I too am a professional unity Dev (just under 10 years).

I'm curious about how your setup looks, do you commit the csproj files (I tend not to as they generate a lot of noise in my experience), do you force the generation of them as part of the ci flow, are you using the dotnet format version that comes with .NET 6 or the version that shipped prior to its move to ship with .NET?

Any advice appreciated

My brief testing this morning seemed to indicate that the latest version of dotnet format shipped with .NET 6 doesn't work with a unity project either (with the .sln and .csproj files removed)

Also I appreciate this has now divulged from being about a Megalinter issue

[bdovaz]

1. I use UseDotNet@2 to install .NET 6.x SDK
2. I run Unity in batch mode to generate the necessary files (*.sln + *.csproj). The key is in: -executeMethod UnityEditor.SyncVS.SyncSolution.
3. I execute the corresponding command of dotnet format.
4. I create a branch, I commit the modified files and I create a PR that has to pass some policies.

As I say, we have this pipeline before integrating Megalinter, so it does not use the dotnet format linter of Megalinter. I have to test to see if doing it with Megalinter works the same way.

[nvuillam]

I don't know what I'm speaking about, but... maybe if it is boring to generate thise .csproj files, an option of MegaLinter (activated or not by default) could generate them during the CI before running dotnet format ?

[sm-quasar]

Ahhh okay, yeah I see how you're getting around the restriction I'm facing, the sync solution approach is one I've used in the past though I think last i tried that it still incurred the import cost, that may have changed now though which would be a big win

My use case is currently running this on all PRs as a GitHub action using GitHub hosted larger runners, so I think in order to avoid installing Unity as part of that particular workflow I may swap to CSharpier

Appreciate all the advice though and I'll check out the sync solution approach for some future automations I'm planning ☺️