- Operating system: Windows 10
- Visual Studio version: 17.10.4
- SonarLint plugin version: 8.1.0.95039
- Programming language you’re coding in: C#
Since one of the last versions of SonarLint I get the error message SonarLint background service failed to start. Some collegues and I made a deep dive the last days to analyse this.
Here are my insights:
- SonarLint Visual Studio extension contains a java JRE
- the extension is stored in a path
C:\Users\{userid}\AppData\Local\Microsoft\VisualStudio\{vs-version}\Extensions\{random-characters}
- JRE is located in
{extension-path}\Sloop\jre\bin
- latest SonarLint VS extension comes with Temurin 17.0.9 (released on October 19, 2023)
- C# class
SonarLint.VisualStudio.Integration.Vsix.SLCore.SLCoreLocator
has a hard-coded string literal for java path inside extension directory - our company uses AppLocker (a windows security feature) to prevent malicious code execution
- executables inside a user directories are not allowed, therefor executing of any binary is blocked (including starting java)
Stacktrace
[ThreadId xxx] [SLCoreHandler] Creating SLCore instance
[ThreadId xxx] [SLCoreHandler] Starting SLCore instance
[ThreadId xxx] [SLCoreHandler] Error starting SLCore instance
[ThreadId xxx] [DEBUG] System.ComponentModel.Win32Exception (0x80004005): {message text by applocker, saying something was blocked from execution}
at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo)
at SonarLint.VisualStudio.SLCore.Core.Process.SLCoreProcess..ctor(SLCoreLaunchParameters launchParameters, ISLCoreErrorLoggerFactory slCoreErrorLoggerFactory)
at SonarLint.VisualStudio.SLCore.Core.Process.SLCoreProcessFactory.StartNewProcess(SLCoreLaunchParameters slCoreLaunchParameters)
at SonarLint.VisualStudio.SLCore.SLCoreRpcFactory.StartNewRpcInstance()
:
:
My suggestions would be
- like the VS Code extension respects the value of
JAVA_HOME
(and other locations) it would be nice if the VS extension would also do this - a SonarLint Light version without a bundled java version would comply more with company rules. It would be fully in scope of a company which java flavor and what version is used.
If desired, I could make a pull request for the first option.