This is a proposal to support more compiler arguments in the generation of CSProject files. Currently a very limited set of compiler arguments are used in the generation of CSProjects. Namely -nowarn and -langversion (Correct me if I'm wrong please) however there are a lot more useful and used compiler arguments. Implementing this would make it easier for end users to use these files and have the same behaviour in both the IDE and in Unity. This will also reduce the amount of hacky CSProject post processing scripts that try to add these themselves.
Beneath is a table of the arguments that in my opinion are useful for Unity projects. Feel free to give feedback and suggest other arguments.
Find the other arguments here.
Argument | Reasoning
------------ | -------------
-doc | Useful for auto generating documentation from your source code that lives in Unity
-reference | Allows you to add extra references that aren't in the Unity project, not sure if needed. Seems kind of niche
-analyzer | Adding analyzers which work both in the Unity compiler and the IDE
-nowarn | Blocks specific warnings for your whole solution
-warn | Sets a custom warning level. This is really useful for external projects you add to your project.
-warnaserror | For the few people that really care about their warnings being fixed
-resource | This probably isn't needed as you could just add the resources in your project. However it might be used if you want to use the same implementation inside of Unity and outside of Unity
-unsafe | Allows pointer magic
-langversion | This is already handled by the Rider plugin, however using the csc.rsp files for this allows for more control.
-ruleset | More analysis usages
-additionalfile | Adds extra files which might be used for analyzers but isn't a ruleset. We use this to add a StyleCop config file to your projects at work.
-define | Defines custom preprocessor symbols, however this is also possible using Assembly references
I would be willing and able to implement some of these myself however I think the source of the Rider package is in a private repo(?).
Thanks for preparing the list. Some of those are already supported. Namely: define, reference, unsafe, nowarn.
langversion is not supported. It can easily be added, but I wonder what should be prefered csc.rsp or preference on Rider tab.
I have started work to support analyzer, ruleset and additionalfile.
Currently there is a publically accessible mirror of Rider package repo: https://github.com/van800/com.unity.ide.rider, but I update it occasionally, manually and only one way. But contributor license is there https://github.com/van800/com.unity.ide.rider/blob/master/Packages/com.unity.ide.rider/CONTRIBUTING.md
So it is only technical problem, not legal one to start accepting PRs.
Alright, I can pick up -doc, -warn, and -warnaserror. Do not forget that some of these have shorthand versions as well.
Cool! I have updated the mirror.
We should most likely regenerate the csproject if the csc.rsp file has changed as it might not always happen.
I've created a PR with the warnlevel implementation, I wasn't sure which branch to use as base so I used the 1.1.3 release.
csc.rsp is inside Assets, so changing it is already monitored, I will check what happens tomorrow.
For now I have a working implementation https://github.com/van800/com.unity.ide.rider/pull/2, but
I forgot about writing tests, will do it later.
Perhaps it's a good idea to parse the otherArguments to a dictionary so that we can just do lookups for which keys we want support. We definitely need to support multiple csc.rsp files as you can have one per asmdef and a project wide one iirc, is there already some support for that?
I think the general rule is that the csc.rsp file is in the root of the project or next to the asmdef.
Let me know what you think: https://github.com/van800/com.unity.ide.rider/pull/2/files#diff-1c7bca91893ac4ebae246878302ebe33R859
I also tried multiple csc.rsp, it work fine at the first glance. Still no tests for now. I have to switch to other task for a while.
Seems good, I'll rewrite mine to support the new structure
I did some csc.rsp + csproj work in a little project of me: https://github.com/MeikelLP/UnityLint.Core/tree/master/Scripts/Editor/Analyzers/Scripting
If it helps you. It basically adds the analyzer x.dll and the given <Analyzer> to the csc and the csproj when I add a dll to a directory.
That's interesting, what do you think about generating a csc.rsp file if you add an analyzer in Rider.
Is there a reason why you're adding the analyzer as a reference to the csc.rsp file? @MeikelLP
One thing to be careful of - if we support all possible options in csc.rsp, but other editors don't, then we need to make sure we don't get into a situation where a project will only build with one editor. We don't want to say that you MUST use Rider to be able to compile/edit a project.
@citizenmatt Unity compiler already uses all data from csc.rsp. (According to Niklasz).
Different Editor would have different project generation, which produces csproj suitable for that editor.
I can't see how we can break workflow for other Editors.
@JurjenBiewenga From what I tested: Unity compiles the code via csc.exe (which uses) the csc.rsp.
.csprojcsc.rspCorrect me if I'm wrong here. It totally works and the compilation pipeline in Unity returns those messages.
@MeikelLP That's correct however there is the -analyzer argument. Which I'm assuming doesn't let you access the classes in the assembly and won't build it with your project.
Here is the "in detail" description of what the -analyzer flag does.
In short: I enforces the compiler to run analyzers for this project.
All functionality added, I will just push in through review process targeting Rider package 1.1.3.
Available in "com.unity.ide.rider": "1.1.3-preview.1"
Would work seamlessly with Rider 2019.2.3+.
For previous Rider versions preview package would require unchecking:

Can someone give an example how the -analyzer argument would look like?
E.g. how to actually add StyleCop.Analyzers.dll ?
@patrickkulling There is example in here https://github.com/vad710/UnityEngineAnalyzer#jetbrains-rider-integration
Let us know, how it works for you.
Thanks @van800 that worked.
However now I am stuck at the problem that it's analysing the whole codebase incl. unity plugins and other 3rd party libraries. But that's a regular roslyn problem - the plugin itself works fine.
If I remember correctly, you may put csc.rsp inside asmdef. You may also describe your solution structure and approach, so we may come up with more specific idea.
The csc.rsp file should either be in the root of your project or in a sub folder next to the asmdef file. If I recall correctly; csc.rsp files in the root of your project count for your whole project even if you define a new one later.
Yeah that's part of our problem, as we are not using asmdef & we currently don't see a great way of introducing it, as we have made more negative experiences with it in the past (esp. with 3rd party dependencies and circular dependencies).
We've recently converted most of our code to asmdef and packages, if you'd like we can chat about it. However Github isn't the right place
@patrickkulling There is example in here https://github.com/vad710/UnityEngineAnalyzer#jetbrains-rider-integration
Let us know, how it works for you.
Hi @van800 I found the example from the link you mentioned above, which says:
Add Assets/csc.rsp with the following content:
-a:"full_or_relative_path_to_UnityEngineAnalyzer.dll"
so where the relative_path based on? I tested relative path based on the csc.rsp file's location, but it doesn't work.
@rugbbyli must be relative to folder, which contains csproj files.
Thanks it works.