Exclude Unity packages from Roslyn Analyzers

I just added some Roslyn analyzers into my Unity project like described here:

Everything works nicely, however I cannot find a way to exclude Unity packages from the analysis. What happens is that when compiling the project, I see bunch of analysis errors and warnings in the console for the files which are actually part of Unity packages. Is there a way to disable the analysis on those?

A workaround that I currently found is that I put my analyzer dlls into the Folder containing the asmdef file instead of putting them into the Assets folder directly. But I don’t like that solution since I have multiple folders containing the asmdef files like this:

Assets/Code/MyNamespace1/MyAsmDef1.asmdef
Assets/Code/MyNamespace2/MyAsmDef2.asmdef
Assets/Code/MyNamespace3/MyAsmDef3.asmdef

and so on.

What I basically want is to exclude the code files which I didn’t write from the analysis.

Any help is highly appreciated!

A way to control the asmdef’s your analyzer runs on, is to have a asmdef(fx. analyzer.asmdef) with an analyzer next to it, and reference the asmdef. Then only the Asmdef’s that references the analyzer.asmdef with the analyzer will include it.

1 Like

@HaraldNielsen thanks for your reply. I think I understand. But what if the analyzer is already compiled - let’s say that I have analyzer dll like ErrorProne.Net.CoreAnalyzers.dll ?

For that you place ErrorProne.Net.CoreAnalyzers.dll next to a asmdef, and then all that reference that asmdef will run with ErrorProne.Net.CoreAnalyzers

Should be described under Scope in https://docs.unity3d.com/Manual/roslyn-analyzers.html
There are currently work getting done to get that page even better :slight_smile:

But imaging we have our N asmdef, and we want to apply the analizers to all those N assemblies. Then we’d have to copy N times de analyzers and place next to the asmdef, isn’t it?

Isn’t there a way to exclude folders? Such as package folder and 3rd party folder?

Thank you

Luckily not, that would be super bad.
https://docs.unity3d.com/2022.1/Documentation/Manual/roslyn-analyzers.html

Read the “Analyzer scope” section, you just have to only reference the asmdef that is next to the analyzer, if you only want to run on part of the assemblies (The ones that reference the asmdef directly)

Correct me if I am wrong, but this approach shouldn’t work for already compiled analyzers, should it?

At least it doesn’t in my tests

Regards

1 Like

Hi @HaraldNielsen , I am trying to do what you have described, but I had no luck.
I have that structure:

- Assets/RoslynAnalyzers/Analyzers.asmdef
- Assets/RoslynAnalyzers/Microsoft.Unity.Analyzers.dll

- Assets/Scripts/FeatureA/FeatureA.Runtime.asmdef
- Assets/Scripts/FeatureA/MyFeatureA.cs

- Assets/Scripts/FeatureB/FeatureB.Runtime.asmdef
- Assets/Scripts/FeatureB/MyFeatureB.cs

I tried adding FeatureA.Runtime.asmdef to Analyzers.asmdef
and adding Analyzers.asmdef to FeatureA.Runtime.asmdef

But none of them work.

@sandolkakos sorry, I totally missed these messages!
Your FeatureA.Runtime.asmdef needs to reference Analyzers.asmdef - Do that work?

@Maeslezo did you get it figured out?

No problem @HaraldNielsen , thanks for getting back to us.
I’ve tried that and it does not work :frowning:

In order to make it easy to test, I prepared that GitHub repository with a small Unity project containing:

  • Assets/RoslynAnalyzers/Microsoft.Unity.Analyzers.dll with Analyzers.asmdef close to it

  • Assets/Scripts/FeatureA/MyFeatureA.cs with a FeatureA.asmdef close to it (having a reference to Analyzers.asmdef)

  • Assets/Scripts/FeatureB/MyFeatureB.cs with a FeatureB.asmdef close to it (without reference to Analyzers.asmdef)

  • Assets/Scripts/FeatureC/MyFeatureC.cs without asmdef (meaning it is part of the Assembly-CSharp.dll)

  • Packages/00 - Simple Package/MySimplePackageScript.cs with an asmdef for testing purposes.

The Microsoft.Unity.Analyzers.dll used in that repo is a compiled version that threats the rule below as error:

Every script described above is a MonoBehaviour with an empty Start method, which should show errors in the Unity Console.

With the settings described above, the analyzer is not catching anything. But if I just delete the Analyzers.asmdef and let the DLL alone, it starts catching all the scripts in the Assets (except the MyFeatureC which has no asmdef) and all the Packages (even the ones from Unity).

I wonder if you could please clone my repo, do some tweaks to make it work, and then tell us where is the mistake.

@ (i forgot the repo link, haha):

Thanks a lot.

@sandolkakos sure! can you share the repo? I dont see it in this thread :stuck_out_tongue:

1 Like

OMG, i forgot the main one, haha. Here you are:

Thanks once more!

1 Like

im also seeing the issue, exactly as described by sandolkakos

1 Like

hey @HaraldNielsen , just pinging you to check if you had a chance to check my repo

Hi @sandolkakos - sorry for the delay!
So I just took a look, and its because we skip compilation of Asmdef’s that dont have any *.cs files. (forgot about this myself)
If you put a *.cs file in, it works. It started reporting the warnings for me after I did that

3 Likes

Yupiiii, thanks a lot @HaraldNielsen , it works.
I will push that class to the repo, so that people will know exactly how it should be set.

8847838--1206151--upload_2023-3-2_17-57-7.png

1 Like

You don’t even need an empty class, an empty .cs file is enough to get it compiled.

3 Likes

Oh nice, I haven’t tried that. Thanks @brunocoimbra :smile:

I’ve noticed what seems to be another bug:

Analyzers in the Assets folder root will run against embedded packages (packages that use “file://…”).

This is annoying if you’re vendoring many of the unity packages as submodules, etc. They’re not in Packages, but they should still get excluded.

1 Like

@HaraldNielsen I have read that section but there are cases that it does not cover as for example if you import an analyzer through https://github.com/xoofx/UnityNuGet.

In that case there is no asmdefs involved and it will scan the whole project.

Isn’t there a manual way to indicate what to scan and what not to scan?

We have performance problems in assembly reloads for this reason…

Every time we update the version of an analyzer (netanalyzers, sonar, meziantou, …) it takes about 10 minutes until Unity responds.

1 Like