VS Extension: The SARIF viewer received one or more SARIF logs in which the analysis tool did not detect any results.

[Kuinox]

Hello, Infer# worked without any issue on another project, but on this project, instead of a list of results, a banner shows up:
No errors appear in the error list.

The analysis seems to have run without issue:

I ran it on my MQTT project: https://github.com/signature-opensource/CK-MQTT/

[matjin]

Oh -- did you compile your binaries locally on your machine? The issue counts reported to the console were detected across the set of binaries that you provided to Infer#. However, we look at the filenames corresponding to each bug and create a new file which only consists of the files that exist locally on your machine, and open that file -- that file would be empty if all the bugs correspond to filenames not on your machine. It is possible that we didn't find bugs in your project persay, but they correspond to upstream library files (i.e. the FluentAssertions you demonstrate above).

[Kuinox]

Oh that would explain it, a lot of the issue reported in the excerpt are issues in my dependencies.

I'm still surprised it doesn't find anything on my 2k lines project :D

[Kuinox]

By reading the report.txt file, it looks like indeed no issues have been found for my files.

[Kuinox]

Ok, in \\wsl.localhost\infersharp1.4\root\infersharp\infer-staging I can see that none of my DLL are present. That's explain why there is no issue found for my code.

[matjin]

I will say also that the Pulse framework fundamentally emphasizes precision, so I'm not too surprised if it doesn't find bugs necessarily. If you run the Linux binaries outside of the extension, you can provide the argument "-F" to enable "latent" issues (vs manifest issues, which is what it would report) -- these are issues which Pulse think can occur contextually but wouldn't necessarily occur, and there are usually many more of these.

[Kuinox]

Is it not because it didn't actually analyzed my DLLs (only some dependencies are in infer-staging ?

If you run the Linux binaries outside of the extension

Sadly I tried to enter the infer WSL distribution but it kinda don't want to:

PS C:\Users\Kuinox> wsl infersharp1.4 /bin/bash: infersharp1.4: command not found

[matjin]

My guess is you need a "-d" -- wsl -d infersharp1.4

Also, if it didn't even analyze the binaries corresponding to your project, then we certainly wouldn't expect any issues on it. Try isolating those binaries alone and rerunning the analysis. Keep in mind that for the analysis we de-dupe by filename for performance reasons, so for example if you have folder1/ConsoleApp1.dll and folder2/ConsoleApp1.dll we only analyze one of them.

[Kuinox]

If it didn't analysed my binaries, that would be a bug in the infersharp VS extension, no ?

[matjin]

No, it should have analyzed your binaries if they were present in the source directory and you used the expected debug build (you have DLL/PDB for each project). They should get copied to infer-staging and then analyzed, unless there is some issue with how the de-dupe logic that I described above works. Can you confirm that you a) have the dlls/pdbs for your project in the initial directory, b) that they get copied into infer-staging?

[Kuinox]

a) have the dlls/pdbs for your project in the initial directory,

Ran the tool on my solution through VS, everything has been compiled in debug mode. I do have dll-pdbs

b) that they get copied into infer-staging?

But it's doesn't get copied in infer-staging

My files names are also somewhat unique:

[matjin]

Do you have the corresponding PDBs as well? This is what I have as output by a debug build on my toy project:

I see DLLs in your directory not the PDBs

[Kuinox]

Mhhhh, the debug metadata is embedded in the DLL for me...

[matjin]

Ah -- we don't yet support PDBs embedded in DLLs. That would be the root issue here. It's a simple fix on our end that I'll try to address this week - will follow up here when I have that out. To mitigate it in the meantime, separating the embedding from the DLLs should work.

[Kuinox]

Thanks! I tracked down why my project did not used the default pdb behavior.
It looks like it's because I'm using DotNet.ReproducibleBuilds and they set it explicitly to embedded:
https://github.com/dotnet/reproducible-builds/blob/956ec68ee3572d3c29e62c7d37aaf076647ab8c8/src/DotNet.ReproducibleBuilds/DotNet.ReproducibleBuilds.props
and in their readme: https://github.com/dotnet/reproducible-builds#dotnetreproduciblebuilds-nuget-package

[xinshiMSFT]

@Kuinox Infer# should have no problem analyzing a .dll file with embedded pdb. The root cause here is that we tried optimizing the binary copying logic (IO between Windows file system and WSL is not great) by only copying .dlls with matching .pdbs without touching anything else.

PR https://github.com/microsoft/infersharp/pull/185 should address this.

[Kuinox]

Ok, thanks for the fix!

[FixRM]

Hello! I have similar issue. I can see in report.txt that some of the issues are coming from my code, but I don't see any errors in VS UI. I have the flowing project structure:

• App (set as analysis root)
• Helper Lib (issues are reported here)