When we initially began our static analysis code scanning process, our code was being built on the same machine that scanning took place. So, when scanning our .NET assembly projects, all sources pointed back to a local directory.
Recently, we've migrated to TFS and builds are occurring on a separate machine. The problem is now all of the source locations in AppScan Source point to a drive mapping that doesn't exist on the code scanning machine. This impacts our ability to inspect scan results. We've tried defining a variable, but this seems to need resetting after every scan.
Is there a best practice for handling source mappings when scanning .NET assembly projects?
NOTICE: developerWorks Community will be offline May 29-30, 2015 while we upgrade to the latest version of IBM Connections. For more information, read our upgrade FAQ.
This topic has been locked.
1 reply Latest Post - 2011-05-10T16:40:16Z by SystemAdmin
Pinned topic Scanning Binaries Built on Different Machine
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2011-05-10T16:40:16Z at 2011-05-10T16:40:16Z by SystemAdmin
SystemAdmin 110000D4XK49 PostsACCEPTED ANSWER
Re: Scanning Binaries Built on Different Machine2011-05-10T16:40:16Z in response to littonuserHello,
We passed this question around internally and it sounds like you were taking the correct approach: setting a variable to abstract away the relative source root on the TFS server.
We have a couple of guesses about what might be going wrong.
1. Are you re-creating the project every time? That might cause the variable to reset depending on how the configuration is done.
2. Does the variable refer to code on another physical volume? I'm not exactly sure how it could happen, but I was thinking that once the variable is applied we attempt to refer to the code via a relative path, which cannot span volumes (drive letters) on Windows.
Ultimately, I think the best approach is to contact support. Setting up a screen sharing session sounds like the simplest way to troubleshoot the issue (or investigate it as a possible feature request if that's appropriate).
My apologies for not having a more concrete answer for you!