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?
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 Posts
Re: Scanning Binaries Built on Different Machine2011-05-10T16:40:16ZThis is the accepted answer. This is the accepted answer.Hello,
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!