I tested the tool. This is just a list of info about everything without context.
Would be great to add Scriptable Contexts with a list of available scriptable checks.
For example, Mobile context shows info for mobile platform, and Desktop context - shows Desktop info. Custom Context shows what you want (for example only allocation info)
Also, scriptable checks give an easy way to extend this tool for custom purposes.
Just tried this tool today. The static code analysis included listing all potential issues preventing a project from disabling domain reload is amazing. I have been long trying to pinpoint all static fields, event subscriptions, etc that were causing issues when domain reload was disabled. I cannot recommend this package enough.
Too late, the original team was laid off February 2024
The original team of what? And February 2024 or 2025? Got a source?
The original team of Project Auditor was axed during the February 2024 round of cuts, source is directly from the original devs themselves:
Edit: Don’t get me wrong, I’m glad it’s released and being supported based on the changelog, but the Unity public repo for Project Auditor hasn’t been updated in over a year.
We have been using an analysis tool called LDRA for our automotive embedded OS for some time now. Its great to see Unity introducing a static analysis tool as well, it always crossed my mind.
Gonna give it a go!
im confused, is it dead?
Unity appears to have a private/internal repo for this version (1.0.0) of Project Auditor. The public repo version (0.11.0) appears dead.
But this thread is a week old and the linkedin post is 11mo old. Maybe its alive
It’s not unusual to internalize the development of a formerly open-sourced project. This has happened to other Unity tools, packages, extensions before. I suppose that’s why there weren’t any more updates to the public repo, it would have just slowed down the team maintaining it.
If anything, the fact that they have not been with the Auditor project for a year and it’s been officially published now is telling that it’s not dead. On top, the way they describe its origins makes the Auditor a very important tool for Unity’s internal use and their paying customers.
That’s a bad take. If that slows a team down, then that’s a politics or a process problem. There are automations that will republish an internal repository while scrubbing the committer history for privacy used by many much larger organizations than Unity.
Again, I’m glad they are maintaining it, but it’s been public and published for years already as evident by the github repo, it would have just been nice to continue with the existing public repo, as now I have to go update all my tooling to deal with it being a package now instead of a public repo…work work
Absolutely true, but still you have a setup cost for something like this and usually it’s not entirely automatic. For instance, does such a thing filter commit messages for obscenities? There’s always some extra amount of discipline to apply when you know it’s for public eyes.
Since I just ran into this yesterday, here’s one of the most infamous vulgar code comments, rightfully so. 
I actually find this an interesting topic, and I’m not responding to just argue for reference.
I’d honestly go so far to say that being worried about bad language in comments goes back to my original statement that it’s a politics or a process problem. In this case I’d call it a politics problem as published packages still contain comments, so that language still exists, and still gets sent to and seen by customers. In fact, the DOTS package has some pretty entertaining comments about things that were hacks or workarounds that needed to be fixed or improved before release (and still not). Now if the code comment was truly foul or vulgar, then I would expect that employee to handled by their manager as that isn’t appropriate in the first place.
This is a nice tool. Although, I’d love to see a Domain Reload profiler and issues for domain reload times, rather than just bugs.
Overall the issues it spotted in my project weren’t major problems, but it didn’t highlight having graphics jobs disabled (which I did not spot in our settings!).
i use linq alot in my project but auditor marks it as major issue. Is it really? its pretty useful instead of nesting loops and conditions
The real answer is that it’s actually complicated. LINQ is useful but it can very easily hide errors, and when used against many container types, it can generate quite a significant amount of garbage that needs to be cleaned up. As such it will cause significant hitching during game play. The simple answer is that it is easier to not use LINQ than it is to go track down each edge case in LINQ usage.
Misused or not, LINQ still generates a lot garbage you can’t avoid. There is a movement to create high performance LINQ but current solutions are somewhat verbose (usage is not that elegant compared to LINQ).
Though at first you should profile to see how much it affects your project.
@rcalt2vt Did you by chance work at an insane little Christian studio in Austin?
LINQ is to C# as templates are to C++. Great for the right things in the right hands. Unfortunately you often encounter them when someone has tried to be too clever with them and created pathologically unoptimized undebuggable nonsense.
what are considered good/bad cases to use it?