Cannot locate class warning in TFS integration
We're working on getting TFS up and running with Fortify. We've got a prod type project into SSC but it had thousands of warnings for things like this...
 Cannot locate class 'System.Object' in the given search path and the Microsoft .NET Framework libraries
That particular warning accounted for 452 of the warnings. It looks like the vast majority of the warnings are similar duplicates. The translation phase of this project took several hours and I'm guessing/hoping it is due to the amount of warnings.
We tried the –libdirs switch but that ate up 4GB of memory just loading the files.So a few questions...
- Recommendations to handle this issue w/ pros & cons?
- Excluding them seems to be an option but it is a good one?
- Is there a setting in one of the .properties files that would handle this?
- We're getting memory errors on our Cloud Scan workers with these build we did not see with Jenkins. Is the sheer amount of errors (+10,000) a factor on the scanning systems memory usage?
- Any other thoughts,suggestions, ideas?
Our setup is doing the translation on the build systems and pass them to a CloudScan setup.We've got 4.1 SCA/CloudScan systems and 4.2 SSC. For the most part with Jenkins it has been pretty smooth. On boarding TFS has been a challenge so far. My hope is this path thing might be an easy fix once we figure it out. Then it'll be on to the next issue
Without the System classes the SCA scan will actually be incomplete - this will be why the memory requirements are so much lower when they're not included. The reason you're seeing these warnings is actually down to a known issue in SCA v4.10. By default SCA should pick up all of the correct libraries from the .NET framework based on the version of .NET being scanned or the -vsversion option. However in v4.10 we're not picking up these libraries, leading to a large number of "Cannot locate class 'System..." warnings and in turn an incomplete scan. As you've correctly found the workaround is to pass the .NET framework dir itself to -libdirs. This is resolved in v4.21 and up.
The increased memory usage is likely down to the fact we're covering the whole app once we have all of the system libraries. For a discussion/possible suggestions on how to handle scans where memory is a limitation check out the .
Also, if you send a debug scan log from Jenkins and one from the CloudScan setup to the team at firstname.lastname@example.org, we can certainly check there's nothing else going amiss in there. The logs will also allow us to explain any other differences.