Respuesta corta: no hay una forma compatible de hacer esto. Pero puedes intentar hackear un poco para resolver esto.

Respuesta larga

Hay varios problemas que tendrías que resolver:

• El escáner SonarQube para MsBuild, que probablemente esté utilizando para enviar el resultado del análisis al servidor SonarQube, está extrayendo las reglas activas del servidor SQ. Luego, esto se pasa a la tarea CoreCompile en msbuild a través del parámetro del conjunto de ruleset . Entonces, incluso si creaste uno propio, eso se eliminaría de los parámetros y se cambiaría al de Sonar.
• El paso final envía los problemas al servidor SQ, pero el servidor SQ ignorará cualquier ID de regla que no se conozca. Entonces, en su caso, se ignorarán todos los problemas de CS* .

Por el momento no creo que haya una solución fácil a estos problemas. La sugerencia general sería crear su complemento SQ, que define todas las reglas de CS* . Obtenga estas reglas en el archivo de conjunto de reglas (probablemente entre la fase de inicio y la de compilación), analice el archivo json de salida y envíe los resultados al servidor. Esto funcionaría, pero es una tarea bastante grande, y hay muchos lugares donde esto puede volverse loco.

Otro enfoque es echar un vistazo al SDK de SonarQube Roslyn . Este SDK le permite crear un complemento de SonarQube a partir de los analizadores nuget de Roslyn. Si crea un complemento de este tipo, verá que tiene 2-3 archivos XML incrustados. Estos archivos describen las reglas del complemento. Para apoyar su caso yo:

• Cree un paquete de analizador Roslyn con una regla. (Lo que no informa ningún problema).
• Cambie los archivos incrustados para definir las reglas de CS* . Probablemente no sea tan fácil obtener una lista de todas las reglas de CS* , pero este podría ser un buen comienzo.
• Implemente el complemento SQ en el servidor SQ y espere que funcione.