search

GregBartlett / sonar-resharper

MIT License
9 stars 21 forks source link

InvalidPathException thrown on second parse of source file that contains a "space" in the path #35

Open stuartmackintosh opened 7 years ago

stuartmackintosh commented 7 years ago

We have a project that contains a space in the project name "Common Libraries" The first time we run the sonar scan including the ReSharper results, everything thing works fine and the results are loaded to SonarQube. The second time however the error below is thrown. We have several projects that are working and the only thing in common I can see with the ones that don't work is a space in the the path.

I've upgraded the sonar-resharper plugin to the latest version (2.17), but we still get the error.

It seems that the path being constructed for the first file in the resharper log is being confused (and duplicated).

java.nio.file.InvalidPathException: Illegal char <"> at index 45: E:\TeamCity\buildAgent\work\b3dd8ed054cf420a\"E:\TeamCity\buildAgent\work\b3dd8ed054cf420a\Source\Common Libraries\ACorns.WCF.DynamicClientProxy\IClientBase.cs

Here is the full execution log.

Sonar End Log.txt

Any help is much appreciated.

GregBartlett commented 7 years ago

Let me take a look, in the meantime if not too much trouble, can you re-run with the -X argument and post the log please.

GregBartlett commented 7 years ago

@stuartmackintosh added a try catch block where i think its failing based on the stacktrace. This is not a fix, but will allow you to complete your scan while i take some more time to identify why it's doing what you reported.

GregBartlett commented 7 years ago

@stuartmackintosh alright v2.18 is out there. It should at least allow you to get through the scan without an exception while I look at the pathing issue.

stuartmackintosh commented 7 years ago

@GregBartlett Here is the log with the /D:sonar.verbose=true option set on the msbuild runner start command. I assume that's the same as the -X option, if not please let me know.

Sonar End Log with DEBUG.txt

I'll install the v2.18 release now, and let you know how it goes.

stuartmackintosh commented 7 years ago

@GregBartlett here is the debug log with version v2.18 the scan does indeed complete now, but the error still occurs in several places.

Sonar End Log v2.18.txt

GregBartlett commented 7 years ago

@stuartmackintosh so sorry for not responding sooner. Completing is better than blowing up the whole scan right :) In the middle of some RL stuff but will try to find the right code fix for the Illegal char issue (which I believe appears to be two pathes being spliced together, but because of the space in Common Library it's wrapping it up in the " "'s and whatever is splicing isn't smart enough to build the path correctly.

Thanks for the log!

GregBartlett commented 7 years ago

@stuartmackintosh When a build completes can you send me the resharper.xml please? E:\TeamCity\buildAgent\work\b3dd8ed054cf420a\resharper.xml the path will change on each execution I think. But really I think any will do, I'm wondering if the path is messed up in the report.xml that is generated that's causing this.

stuartmackintosh commented 7 years ago

Here you go.

resharper.zip

GregBartlett commented 7 years ago

@stuartmackintosh so I have no idea where it's putting together this crazy path you are getting. I'm checking in a change that attempts to detect this crazy path and fix it. Attached is the build with the fix in it. Please give it a test and let me know the results before I post it on the releases page.

Thanks for your help and willingness to send the requested files :) sonar-resharper-plugin-v2.19-SNAPSHOT.zip

stuartmackintosh commented 7 years ago

@GregBartlett I've re-run the test and there is no change... I wasn't sure that the new version was being used as the version number in SonarQube showed as only 2.1-SNAPSHOT, so I completely uninstalled it and reinstalled it. However nothing changed. I've also upgraded the version of the ReSharper command line tool to 2016.3.2, still no change.

Sonar.End.Log - beta.txt

GregBartlett commented 7 years ago

@stuartmackintosh thanks, it helps me narrow it down.

GregBartlett commented 7 years ago

@stuartmackintosh in regards to the sonarqube version, looks like it's getting it from the pom.xml. Will see if I can get appveyor to update the pom.xml as well to reflect build number.

GregBartlett commented 7 years ago

@stuartmackintosh so it has to be something that Sonarqube's FileSystem object is doing when it's trying to find the file. I'll look at it some more, but we are narrowing it down, thanks for your time:) inputFile = fileSystem.inputFile( fileSystem.predicates().and( fileSystem.predicates().hasAbsolutePath(file.getAbsolutePath()), fileSystem.predicates().hasType(InputFile.Type.MAIN))

GregBartlett commented 7 years ago

@stuartmackintosh I posted on the sonarqube google group: https://groups.google.com/forum/#!topic/sonarqube/44IUUH3A1vc

I am not totally familiar with sonarqube's api, and from the stack traces before it's clearly going into the sonarqube's FileSystem API to locate the file. I'm hopefuly somoene out there can help me figure out why the sonarqube file cache is storing funky paths.

GregBartlett commented 7 years ago

haven't heard anything from anyone on the google group yet :(, will keep looking at it when i have time though